Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

--relocatable is not reliable #90

Closed
carljm opened this Issue Mar 15, 2011 · 9 comments

Comments

Projects
None yet
8 participants
@carljm
Copy link
Contributor

carljm commented Mar 15, 2011

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

This comment has been minimized.

Copy link
Contributor Author

carljm commented Mar 15, 2011

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

This comment has been minimized.

Copy link

un33k commented Aug 19, 2011

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

@jmagnusson

This comment has been minimized.

Copy link

jmagnusson commented Apr 23, 2013

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

This comment has been minimized.

Copy link

CtrlC-Root commented Oct 2, 2013

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.

@dstufft dstufft referenced this issue Jan 5, 2015

Closed

Rewrite virtualenv #697

0 of 5 tasks complete
@franciscolourenco

This comment has been minimized.

Copy link

franciscolourenco commented Jun 6, 2015

+1

1 similar comment
@farridav

This comment has been minimized.

Copy link

farridav commented Aug 24, 2015

+1

@CtrlC-Root

This comment has been minimized.

Copy link

CtrlC-Root commented Aug 24, 2015

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.

@Ivoz Ivoz removed the launchpad label May 29, 2016

@arizvisa

This comment has been minimized.

Copy link

arizvisa commented May 29, 2018

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 comment has been minimized.

Copy link

stale bot commented Jan 14, 2019

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.

@stale stale bot added the wontfix label Jan 14, 2019

@stale stale bot closed this Jan 21, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.