Make --relocatable even more relocatable #558

Open
omribahumi opened this Issue Jan 29, 2014 · 6 comments

Projects

None yet

6 participants

@omribahumi

Apparently even when running virtualenv --relocatable on my virtualenv, it's still not entirely relocatable:

  1. Links in ${VIRTUAL_ENV}/local are absolute instead of symbolic
  2. VIRTUAL_ENV environment variable defined in bin/activate is hard-coded

I'm thinking of fixing these myself, here's how I thought of doing it:

  1. Walk the virtualenv directory tree, make all absolute links to destinations inside the virtualenv relative (absolute links to paths outside of the virtualenv root will stay absolute)
  2. Replace hard-coded virtualenv path with bash magic (similar to this):
VIRTUAL_ENV="$( cd "$( dirname "${BASH_SOURCE[0]}" )/.." && pwd )"

Any thoughts?

Omri.

@elistevens

@omribahumi have you started on this?

Is there a reason those links aren't relative to start with? It's not clear if there's a firm reason why virtualenvs don't start off relocatable.

@omribahumi

@wickedgrey I wrote an external script to update the relevant files. I didn't want to maintain a fork of virtualenv.

I see no reason not to make the links symbolic globally, as you said.
One more thing we should consider is /bin/sh compatibility. My 2nd suggestion involves a BASH trick that doesn't work with /bin/sh.

We can add a new activate script though: activate.bash

@aristidesfl

+1

@kairichard

+1

@dbarbeau
dbarbeau commented Jul 22, 2016 edited

Yes, the bash activate script should set VIRTUAL_ENV with bash magic. This would help a ton when packaging our projects for use with external tools like uwsgi. So a huge +1.

However, as stated earlier, this doesn't concern --relocatable, but activate which should be modified with that black magic.

Are there strong motivations against this change?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment