Join GitHub today
--relocatable is not reliable #90
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), '..'))" "$0"
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 similar comment
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.
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.