[crdoconnor]

I usually do this just by cd'ing to the project directory, which has the virtualenv inside it and running './venv/bin/python'.

That eliminates the possibility that I'll accidentally run the wrong version of python - e.g. a system python or a python from another environment that didn't properly deactivate.

Most other issues are easy to deal with (e.g. non-existent virtualenv, being in the wrong folder), but the issue of accidentally using the wrong environment is awful because it can manifest itself with subtle bugs or weird exceptions rather than an obvious error.

[e12e]

I mostly do this, along with a little hack for certain commands I need, such as mercurial: I have a virtualenv under ~/opt/venv/py-2.7-misc, and make a symbolic link from ~/opt/venv/py-2.7-misc/bin to ~/opt/pybin -- and then my .bashrc checks for a ~/pybin and adds it to the PATH if it exists ( [[ -d "${HOME}/pybin" ]] ...).

So I can just go "pip install -u mercurial", or "pip install <some useful utility>" without worrying too much. And (my) "hg" is in my PATH -- and I can still run stuff in custom virtualenvs on a project basis, just as you say, by specifying the full path (./proj/venv/bin/python ...).

I've never understand why people use anything more complicated.

I do see occasions where activate is useful -- certain packages, I think scipy and pygame are among them -- are not only rather difficult to install via pip, but also tend to be very picky about their environment. Normally I get by by just installing those (and other packages with strong c/c++ library dependencies) via the package manager though.