Relocatable

[Acrisel]

Replace hard coded path in 'activate' scripts (batch and shell) with relative path. Each activate script will be fixed to have relative evaluation of its path. For example, in bash activate:

VIRTUAL_ENV="$(dirname $(dirname $(readlink -f -n $BASH_SOURCE)))"

References:
#11
https://bugs.python.org/issue27148

[pfmoore]

The same reasons for rejecting this suggestion that were given in the linked bug report for venv apply here as well:

1. Virtual environments aren't meant to be moved, they are cheap to create and the recommended approach if you want to move an environment is simply to recreate it in the new location.
2. Packages installed into a virtualenv will have the absolute path to the Python interpreter hard coded into any entry point wrappers that get installed, so moving the environment would break these even if the activate script was modified as suggested.

[Acrisel]

This is my two cents:

1. Making virtualenv movable make it easier in deployment from development, to test, and into production envrionment. Cheap as it may be to create, you have to reinstall packages that take time. If you have hundreds of server servers to install and maintain, that can take its toll. Maintaining one virtualenv and distributing it to servers is a safer way.
2. We are doing all the time, creating virtualenv. Then, modifying its scripts to be movable. Then we have a single environment that we know is right, and we ship that environment to all server.
3. others are doing it too. Just search the web for issue in relocatable virtualenv activate.bat or bash and you will find plenty that overcome this issue. So solving it in the core can benefit everyone.

[arizvisa]

Is there really no interest in the eyes of the developers to make each of the activation scripts relocatable (after deployment) by utilizing relative paths? You can even still support the old absolute path functionality via a tiny modification to the activation scripts.

For bash || cygwin, you can dep on readlink -f $0, or you can canonicalize the paths.
For .bat files depending on cmd.exe, you can use ~dp0 as previously suggested.
For Powershell, you guys are already doing this via $myinvocation.mycommand.path

I'd submit a PR, but if it's going to be rejected (despite it being such a common use-case). Then it'd be better to just fork virtualenv into a virtualenv-relocateable project and just let it suffer from lack of maintenance.

Hell, after writing this comment it looks like people are already doing this? (https://github.com/firedrakeproject/relocate-venv, https://www.alexhudson.com/2013/05/24/packaging-a-virtualenv-really-not-relocatable/, https://mike.zwobble.org/2013/09/relocatable-python-virtualenvs-using-whack/, https://groups.google.com/forum/#!topic/python-virtualenv/wM2NkAOZS4E, https://www.alexhudson.com/2013/05/24/packaging-a-virtualenv-really-not-relocatable/, etc...)

[arizvisa]

Ftr, it looks like PR #236 aimed to fix this, but was closed due to lack of maintenance. Should we resurrect it?

[adah1972]

I've just written an article on how to make the virtual environment relocatable. To repeat what I wrote:

The reason I need to make virtual environments movable is that our clients do not usually allow direct Internet access in production environments, therefore we cannot install packages from online sources on production servers. They also often enforce a certain directory structure. So we need to prepare the environment in our test environment, and it would be better if we did not need to worry about where we put the result on the production server.

I'll second Acrisel that this is a real need.

[adah1972]

This said, I'll repeat what I said in the old issue #11: the use of readlink is problematic due to differences between Linux and BSD/macOS/other*nix. This would be more portable:

VIRTUAL_ENV=$(cd $(dirname "$BASH_SOURCE"); dirname `pwd`)

[arizvisa]

If anybody is interested in this, I created a patch for Python 2.7 that fixes some broken functionality with how it locates the site-packages and everything so that it'll actually use the location of the Python library. This way if Python isn't installed globally (or written into the registry) on Windows, it'll fall back to its path which removes the need to tweak the activation scripts like we've been doing.

https://bugs.python.org/issue35173

Literally on Windows, you'll just need to move the Python DLL to the base of where your site-packages are, then you can run Python from that directory w/o having to activate it even. If you use it, lmk if you have any strange issues as it "works for me". ;)

(edited to include directions of placing the Python DLL)

[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.

[andre-merzky]

I would still like to see this addressed. I am in the same boat as others above, and need to use a virtualenv on a (large) machine which has a very strict outgoing firewall, and can't recreate the environment. Having to manually fix the virtualenv everytime I do an update etc. is very time consuming and annoying.

[gaborbernat]

@andre-merzky have a look at #1473; we don't want to solve the problem ourselves as it cannot be done for all platforms universally, so we'll defer to other tools/plugins built on top of virtualenv, that solves the problem well for a given platform.