The activate/deactivate magic is responsible for some real nastiness in deployment scripts, and total confusion for beginners who are thrown by the statefulness. Virtualenvwrapper makes the situation even worse by hiding the virtual environments away.
By far the easiest way to use virtualenv is to forget about activation completely, and directly reference the binary you want to use. For example, rather than typing:
Depends on what you are running and from where. The usual virtualenv activate (although I recommend virtualenvwrapper's workon) works fine for a human interacting with a terminal.
But it is annoying for bash scripts, extremely annoying for Fabric scripts where each command is run in a separate SSH session, and sometimes completely impossible when a server needs to spawn a python subprocess. Used this exact method to solve issues with nginx+uwsgi web server deployments a few weeks ago.
Using the full path to the virtualenv's python works in any context, even when you can't set environment variables or run two commands.
with prefix('source venv/bin/activate'):
I've got plans to address this sort of complaint, to let folks who like the current behavior to keep working the way they always have and enable those like me who want a "keep all the state in a subshell" behavior to get my proposed workflow.
As one commenter points out, those plans haven't moved forward since mid 2012. I don't consider the issue "dropped" though. I'll get around to it.
Really? Most of the time when people say that they mean "for 1 (me) of us,"
Are you sure that isn't what you mean?
Whenever I stumble across a new problem and google for it there is a huge wealth of information about what's causing it and what the workarounds are. That's great news for me, but not so great for your bullshit 99.99% figure. A rather large number of people have run into the same problems, a huge number if you assume that most of them don't post about it since someone already has.
Also funny is that there are now decades of experience with shell tools and programs, much more than there is with python, nevermind virtualenv. Perhaps they have best practices for a reason?
It makes things easy. The system python is kept clean and I don't have to deal with it.
I'm guessing it's also why "hard" classes in school start with the concepts rather than the magic (physics is a perfect example). You can't really go far if you don't get the concepts.
I've been doing some training lately for new hires, and I am inclined to start with the concepts and then teach the magic, but I wonder if it's the most effective way to learn in the short term?
Fear leaky abstractions, though.
I really liked the way she distinguished arbitrary variable names from mandatory class names etc. So often, tutorials don't make that clear.
You're right about 'source' though, shell scripts that want a semblance of portability must use '.'.