Virtualenv's `bin/activate` is Doing It Wrong

gistfile1.md

This article is now published on my website: Prefer Subshells for Context.

@orodbhen, PS1_CONTEXT is just an example I made up of "various ways to stuff things into your prompt without clobbering $PS1." You could have other scripts that assign the current git branch to that variable whenever you're in a git repo, for example. If it's unset, it doesn't do anything.

It's a good observation that adding the venv setting to the current shell is a bit problematic. Unfortunately, I think you throw the baby out with the bathwater and create a couple of new problems in the process.

Don't do away with activate, keep it and use it instead. Then there's no need to duplicate its logic in inve, just use this:

#/bin/bash
"`dirname $0`/activate"
exec "${@:-$SHELL}"

That way you don't break everyone who edited activate to add custom logic (like jdawsongit). That also allows you to get rid of the eval hack as well - just keep using activate for these occasions. No need to bend over backwards for something that activate gives you for free.

Finally, the system-level inve is broken. It seems to assume it's executed with a $PWD somewhere under the venv directory. From my understanding, it's not common to actually have a shell open under the venv path, since you typically have your project source code next to the venv, not inside it (so you can nuke and recreate your venv, if need be). The system-level inve also changes the current directory, which is a horrible idea. That breaks many use-cases, for example

inve py.test ./tests    # Yeah, '.' is not what you thought it was :-(

So there's a good idea here, but I think the solution creates more problems than it solves. Especially the system-level inve can't be used as-is. I'm not sure whether it's salvageable, you'd need a way to discover venvs in parent directories, which seems tricky and error-prone. At the very least, use pushd/popd to avoid changing the current directory for the childs you execute!

I'm relatively new to Python though I've been around long enough to appreciate Unix-friendly approaches. My first tries at getting activate to work failed, so I turned to The Internet for instructions. Your article came up, and pointed me at vex. Vex worked great, and it feels much more in line with the tools I've come to expect from the CLI. This will probably go double when I start mucking about with FreeBSD, I know BASH is not the standard shell over there.

Thanks for your article and the included recommendations.

I've been using conda for a while and the same problem was bothering me.
Conda has an virtualenv's style activate and it was very annoying to use the envs on a non-console application (IDE).

So I created exec-wrappers to be able to create wrappers ready to use with minimum overhead.
It also happens to create wrappers for virtualenv. So if someone is interested, please take a look.

All I can say is +1

great article. It is exactly what people need when python is integrated to other technologies (like java). python code probably is called with not terminal in the middle. This article solved my problem.

forget pip - pip3
use conda https://conda.io/docs/_downloads/conda-cheatsheet.pdf

This is great. I would just note that there is no need to hard code the path of the virtualenv in shell and batch scripts. It can and should be relative.

Please also look at vrun [1] which is super lightweight and simply activates a virtualenv for the duration of a command. You run something like env/bin/vrun <cmd> and it is executed with all of the virtualenv scripts etc on the path. This is similar to vex but with fewer assumptions and should be mentioned in the same conversation.

[1] https://pypi.org/project/vrun/

Helpful! Thank you!!

404 on the link 👎

still 404

@nmaupu , @benedikt-bartscher: here is a copy of the page on the Wayback Machine from archive.org.