Issue 25833: pyvenv: venvs cannot be moved because activate scripts hard-code paths (original) (raw)

Issue25833

Created on 2015-12-10 15:15 by moorecm, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (3)
msg256176 - (view)	Author: Chad Moore (moorecm)	Date: 2015-12-10 15:15
venv/bin/activate contains an absolute path to the virtual environment. Is it possible to make that relative from activate itself so that the entire venv can be moved elsewhere and still work? I found this using Jenkins to get a Perforce workspace, then build a virtual environment, and clone that for downstream jobs. The cloned workspaces are extracted elsewhere and when they activate the environment they're actually pointing back to the upstream job's venv. Feel free to route this request as appropriate. I'm a new tracker user. Thanks!
msg256177 - (view)	Author: R. David Murray (r.david.murray) *	Date: 2015-12-10 16:30
It's been that way since the virtualenv days, and I presume there's a reason for it. virtualenv does have a '--relocatable' option, but it is still marked as experimental. Finding out why that is and addressing the issues would be a prerequisite for adding this enhancement to venv.
msg260228 - (view)	Author: Vinay Sajip (vinay.sajip) *	Date: 2016-02-13 09:47
Indeed, and in fact *all* scripts written to a venv's bin directory hard-code the path to that venv's interpreter. This confers the benefit that such scripts never need the venv to be explicitly activated - you can e.g. point crontab entries to them directly. You're better off making the Jenkins job build the environment in its workspace before using it - venvs are intended to be reproducible and, consequently, disposable.