Something for your fabfile (for pushing to production and migrating):

  def with_virtualenv(command):
      "Executes a command in this project's virtual environment."
      run('source /usr/local/bin/virtualenvwrapper.sh && workon %s && %s' % (env.virtualenvname, command), pty=True)

e.g. usage: with_virtualenv('python manage.py migrate')

For your local development, throw the virtualenv wrapper initialization into your bashrc (Only need to do this once.)

  echo "source /usr/bin/local/virtualenvwrapper.sh" >> ~/.bashrc

When you're developing, always start by activating your virtual environment.

Why would I need to do that? I can just change the shebang line in manage.py and never ever need to activate the virtualenv...

One of the big benefits of using virtualenv is that you can change the environment your code is running within. For example, if I want to test a new version of a package (or a new version of python altogether), I can create another virtual environment and "workon [newenvname]", ./manage.py runserver..., and test away.

It also follows the principal of least surprise. As a developer, if I run a python file, I generally expect it to use the python version in my environment, not some hard coded path. This is exactly why manage.py references python in the environment (/usr/bin/_env_) and not a direct path to the python executable.

It's easy to switch virtual environments and unexpected that I'd have to change code.

I could be wrong.