--relocatable is not reliable

[carljm]

Originally reported by Chris Adams at https://bugs.launchpad.net/virtualenv/+bug/417071

I have a project which is distributed in an RPM which provides a pre-configured virtualenv with the core application and the modules which aren't standard enough to install system-wide. Our build script uses "virtualenv --relocatable" to fix the full paths which point into the RPM build directory by default.

This revealed a fair number of things which virtualenv --relocatable misses in the bin directory. This includes versioned pythons (e.g. #!/path/to/python2.5) and, apparently, anything which takes an argument - e.g. I found that while pytest.py uses "#!/path/to/python -u" --relocatable says it cannot be made relative (it's not a normal script that starts with #!/path/to/python)". It'd probably make sense to change the logic slightly to replace "$VIRTUAL_ENV/bin" in every shebang.

The activate script also has a hard-coded path, which would be harder to make relative. The easiest path would be using dirname and realpath to the directory above activate but that's not as universally available as basename. For the activate script it might be acceptable to take a little more performance hit of something like python -c "import os, sys; print os.path.realpath(os.path.join(os.path.dirname(sys.argv[1]), '..'))" "$0"

[carljm]

From https://bugs.launchpad.net/virtualenv/+bug/475325

The lib64 symlink in the virtual python directory is symlinked to the absolute path of the lib directory. The --relocatable option doesn't change this...

It seems to me the symlink should either be created with a relative path initially or changed to a relative path by the --relocatable option.

-bash-3.1$ virtualenv --version
1.3.4dev
-bash-3.1$ virtualenv testpy
New python executable in testpy/bin/python2.4
Not overwriting existing python script testpy/bin/python (you must use testpy/bin/python2.4)
Installing setuptools.............done.
-bash-3.1$ ls -l testpy/lib64
lrwxrwxrwx 1 ncohen sts-cr 27 Nov 5 11:12 testpy/lib64 -> /home/sts/ncohen/testpy/lib
-bash-3.1$ virtualenv --relocatable testpy/
Making script testpy/bin/easy_install-2.4 relative
Making script testpy/bin/easy_install relative
-bash-3.1$ ls -l testpy/lib64
lrwxrwxrwx 1 ncohen sts-cr 27 Nov 5 11:12 testpy/lib64 -> /home/sts/ncohen/testpy/lib

[un33k]

will, it will not honour the --no-site-packages, which make it very un-relocatable. it defeats the purpose of having a virtualenv in the first place

[jacobsvante]

Has any work been done in this area? This is a great feature to have when deploying as you won't have to rely on (sometimes very slow) external indexes to get a virtualenv up and running.

[CtrlC-Root]

Not to mention being able to more easily package virtual environments. A big plus to those of use who don't want to package python libraries.

[franciscolourenco]

+1

[farridav]

+1

[CtrlC-Root]

So I used to do the same thing. Package virtualenvs as RPMs. It took some work but I ended up with a script that would fix a virtualenv so it would be relocatable. It's not a very sustainable approach. Why not package your application using the Twitter PEX format first and then put the .pex file into the RPM? That way you get all the benefits of a relocatable virtualenv without any of the magic.

EDIT: https://engineering.twitter.com/university/videos/wtf-is-pex

EDIT2: For those of you unfamiliar with the PEX format, all you need is a matching version of python on the target machine. Everything else is packaged inside a single .pex file you can move around.

[arizvisa]

Adding a reference to the newest issue #1067 related to this to help consolidate efforts on solving this half-decade old problem with the activation scripts.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Just add a comment if you want to keep it open. Thank you for your contributions.