6 ms·

Show HN: Virtualenv-mv – Move (rename) Python virtualenvs

42 points by brbsix 10y ago

bonobo3000 10y ago
this is cool, ive been burned by trying to move a virtualenv before and discovering everything broke. is it possible to merge this into virtualenv? i think it would be much easier to use that way.
RodericDay 10y ago
why is this necessary? shouldn't you just delete it and recreate it? installation via pip ought to take advantage of wheels and such, no?
- snuxoll 10y ago
  Would be useful for packaging up a virtualenv in an RPM (though I avoid doing that for various reasons), if there was an option to fix the paths without actually performing the move.
  - meddlepal 10y ago
    Oh god. I just went through this shit show for a .deb archives. Python is an absolute nightmare to package and distribute this way.
    - Spiritus 10y ago
      Perhaps this is useful for you? https://github.com/spotify/dh-virtualenv https://github.com/spotify/dh-virtualenv
      - meddlepal 10y ago
        I looked at that but didn't use it because I wanted to avoid adding yet another packaging tool into our toolbox. Instead I use virtualenv-tools and fpm. We use FPM for packaging needs and it works well enough.
  - falsedan 10y ago
    Last time I did this, I used pip with --download on the build server, and --no-index & --find-links on the deployment target into a virtualenv in /usr/share/<package_name>. It was a pain to get the pre- & post-actions right. This still required internet access btw, but at least the deployments didn't fail when a host serving packages was unavailable.
- noisy_boy 10y ago
  The machine you are installing from may not have access to internet. Then you'll need a setup to supply pip the packages. If virtualenv was truly relocatable, you can install once, push all to git and just fetch wherever you need.
has2k1 10y ago
There is https://github.com/berdario/pew https://github.com/berdario/pew which provides a better wrapper around virtual environments compared to virtualenv wrapper. It also supports renaming.
- brbsix 10y ago
  Albeit less featureful than pew or virtualenvwrapper, pyenv[0] is great also. It looks like pew uses virtualenv-clone[1] internally. However a casual test indicated quite a few shebangs unmodified and in the case of venv, the activation scripts as well. [0]: https://github.com/yyuu/pyenv https://github.com/yyuu/pyenv [1]: https://pypi.python.org/pypi/virtualenv-clone https://pypi.python.org/pypi/virtualenv-clone
- m_mueller 10y ago
  > a better wrapper around virtual environments compared to virtualenv wrapper This comment alone tells me there's something wrong about python's modularisation. And I'm saying this as a python programmer. Why didn't Python 3 clean up this mess? Or am I missing something there?
  - pekk 10y ago
    virtualenvwrapper isn't part of virtualenv or python. Are you saying that the existence of virtualenv tells you there's something wrong?
    - hkjgkjy 10y ago
      I would agree to that yes, as are most (all) languages. It would be very nice if the Python version was something specified in the project manifest. Don't know what is the popular build tool in python, but something like specifying the node.js version in the package.json file would be great. I think the reason it never works like that is that the language is written before the package manager and VM/compiler. In Clojure it's the other way around - the JVM and the package managers were there before the language. The Clojure compiler is a library that you include in your project.clj file like any other lib. Hence you can specify language version per project. That's a feature I would like to have in other programming environments.
andy_ppp 10y ago
This should be called virtualenv-rename right, otherwise what does virtualenv --relocatable do? Python/Java using the file system to map hierarchies of classes is such a mistake when you start using a language like Elixir; you can move any .ex files anywhere you like within your project and it just works.
- brbsix 10y ago
  The script is most akin to the Unix `mv` command, in fact it uses it, so that's why I called it virtualenv-mv. I figured this would be most easily understood. Just out of curiosity, have you used `--relocatable` much? It basically attempts to rewrite full paths into relative paths. Whereas with `virtualenv-mv`, there should be no indication that the environment has been moved. As far as `--relocatable` is concerned... I think even the author(s) regret having included it, if that gives you any indication of how useful it is.
  - andy_ppp 10y ago
    Why would you rename a virtualenv? They should be named "env" and you should change the prompt that pops when you enter it to be something like "(VENV: projectname)".
    - 88e282102ae2e5b 10y ago
      You might want to move our copy it to another directory. I had this problem recently when I wanted to use an env that had a bunch of packages that take a long time to compile, but since it didn't work I had to reinstall them in a new env.

42 points by brbsix 10y ago

this is cool, ive been burned by trying to move a virtualenv before and discovering everything broke. is it possible to merge this into virtualenv? i think it would be much easier to use that way.

RodericDay 10y ago

why is this necessary? shouldn't you just delete it and recreate it? installation via pip ought to take advantage of wheels and such, no?

snuxoll 10y ago
Would be useful for packaging up a virtualenv in an RPM (though I avoid doing that for various reasons), if there was an option to fix the paths without actually performing the move.
- meddlepal 10y ago
  Oh god. I just went through this shit show for a .deb archives. Python is an absolute nightmare to package and distribute this way.
  - Spiritus 10y ago
    Perhaps this is useful for you? https://github.com/spotify/dh-virtualenv https://github.com/spotify/dh-virtualenv
    - meddlepal 10y ago
      I looked at that but didn't use it because I wanted to avoid adding yet another packaging tool into our toolbox. Instead I use virtualenv-tools and fpm. We use FPM for packaging needs and it works well enough.
- falsedan 10y ago
  Last time I did this, I used pip with --download on the build server, and --no-index & --find-links on the deployment target into a virtualenv in /usr/share/<package_name>. It was a pain to get the pre- & post-actions right. This still required internet access btw, but at least the deployments didn't fail when a host serving packages was unavailable.
noisy_boy 10y ago
The machine you are installing from may not have access to internet. Then you'll need a setup to supply pip the packages. If virtualenv was truly relocatable, you can install once, push all to git and just fetch wherever you need.

has2k1 10y ago

There is https://github.com/berdario/pew https://github.com/berdario/pew which provides a better wrapper around virtual environments compared to virtualenv wrapper. It also supports renaming.

brbsix 10y ago
Albeit less featureful than pew or virtualenvwrapper, pyenv[0] is great also. It looks like pew uses virtualenv-clone[1] internally. However a casual test indicated quite a few shebangs unmodified and in the case of venv, the activation scripts as well. [0]: https://github.com/yyuu/pyenv https://github.com/yyuu/pyenv [1]: https://pypi.python.org/pypi/virtualenv-clone https://pypi.python.org/pypi/virtualenv-clone
m_mueller 10y ago
> a better wrapper around virtual environments compared to virtualenv wrapper This comment alone tells me there's something wrong about python's modularisation. And I'm saying this as a python programmer. Why didn't Python 3 clean up this mess? Or am I missing something there?
- pekk 10y ago
  virtualenvwrapper isn't part of virtualenv or python. Are you saying that the existence of virtualenv tells you there's something wrong?
  - hkjgkjy 10y ago
    I would agree to that yes, as are most (all) languages. It would be very nice if the Python version was something specified in the project manifest. Don't know what is the popular build tool in python, but something like specifying the node.js version in the package.json file would be great. I think the reason it never works like that is that the language is written before the package manager and VM/compiler. In Clojure it's the other way around - the JVM and the package managers were there before the language. The Clojure compiler is a library that you include in your project.clj file like any other lib. Hence you can specify language version per project. That's a feature I would like to have in other programming environments.

andy_ppp 10y ago

This should be called virtualenv-rename right, otherwise what does virtualenv --relocatable do? Python/Java using the file system to map hierarchies of classes is such a mistake when you start using a language like Elixir; you can move any .ex files anywhere you like within your project and it just works.

brbsix 10y ago
The script is most akin to the Unix `mv` command, in fact it uses it, so that's why I called it virtualenv-mv. I figured this would be most easily understood. Just out of curiosity, have you used `--relocatable` much? It basically attempts to rewrite full paths into relative paths. Whereas with `virtualenv-mv`, there should be no indication that the environment has been moved. As far as `--relocatable` is concerned... I think even the author(s) regret having included it, if that gives you any indication of how useful it is.
- andy_ppp 10y ago
  Why would you rename a virtualenv? They should be named "env" and you should change the prompt that pops when you enter it to be something like "(VENV: projectname)".
  - 88e282102ae2e5b 10y ago
    You might want to move our copy it to another directory. I had this problem recently when I wanted to use an env that had a bunch of packages that take a long time to compile, but since it didn't work I had to reinstall them in a new env.