Tips and Tricks

This is a list of user-contributed tips for making virtualenv andvirtualenvwrapper even more useful. If you have tip to share, drop mean email or post a comment on this blog postand I’ll add it here.

zsh Prompt

From Nat (was blogger.com/profile/16779944428406910187):

Using zsh, I added some bits to $WORKON_HOME/post(de)activate to showthe active virtualenv on the right side of my screen instead.

in postactivate:

  1. PS1="$_OLD_VIRTUAL_PS1"
  2. _OLD_RPROMPT="$RPROMPT"
  3. RPROMPT="%{${fg_bold[white]}%}(env: %{${fg[green]}%}`basename \"$VIRTUAL_ENV\"`%{${fg_bold[white]}%})%{${reset_color}%} $RPROMPT"

and in postdeactivate:

  1. RPROMPT="$_OLD_RPROMPT"

Adjust colors according to your own personal tastes or environment.

Updating cached $PATH entries

From Nat (was blogger.com/profile/16779944428406910187):

I also added the command ‘rehash’ to $WORKON_HOME/postactivate and$WORKON_HOME/postdeactivate as I was having some problems with zshnot picking up the new paths immediately.

Creating Project Work Directories

Via James:

In the postmkvirtualenv script I have the following to create adirectory based on the project name, add that directory to the pythonpath and then cd into it:

  1. proj_name=$(basename $VIRTUAL_ENV)
  2. mkdir $HOME/projects/$proj_name
  3. add2virtualenv $HOME/projects/$proj_name
  4. cd $HOME/projects/$proj_name

In the postactivate script I have it set to automatically changeto the project directory when I use the workon command:

  1. proj_name=$(basename $VIRTUAL_ENV)
  2. cd ~/projects/$proj_name

Automatically Run workon When Entering a Directory

Justin Abrahms postedabout some code he added to his shell environment to look at thedirectory each time he runs cd. If it finds a .venv file, itactivates the environment named within. On leaving that directory,the current virtualenv is automatically deactivated.

Harry Marrwrote a similar function that works with git repositories.

Installing Common Tools Automatically in New Environments

Via rizumu (was rizumu.myopenid.com):

I have this postmkvirtualenv to install the get a basic setup.

  1. $ cat postmkvirtualenv
  2. #!/usr/bin/env bash
  3. curl -O http://python-distribute.org/distribute_setup.p... />python distribute_setup.py
  4. rm distribute_setup.py
  5. easy_install pip==dev
  6. pip install Mercurial

Then I have a pip requirement file with my dev tools.

  1. $ cat developer_requirements.txt
  2. ipdb
  3. ipython
  4. pastescript
  5. nose
  6. http://douglatornell.ca/software/python/Nosy-1.0.tar.gz
  7. coverage
  8. sphinx
  9. grin
  10. pyflakes
  11. pep8

Then each project has it’s own pip requirement file for things likePIL, psycopg2, django-apps, numpy, etc.

Changing the Default Behavior of cd

Via mae:

This is supposed to be executed after workon, that is as apostactivate hook. It basically overrides cd to know about theVENV so instead of doing cd to go to ~ you will go to the venvroot, IMO very handy and I can’t live without it anymore. If you passit a proper path then it will do the right thing.

  1. cd () {
  2.     if (( $# == 0 ))
  3.     then
  4.         builtin cd $VIRTUAL_ENV
  5.     else
  6.         builtin cd "$@"
  7.     fi
  8. }
  9.  
  10. cd

And to finally restore the default behaviour of cd once youbailout of a VENV via a deactivate command, you need to add thisas a postdeactivate hook:

  1. unset -f cd

Clean up environments on exit

Via Michael:

When you use a temporary virtualenv via mktmpenv or if you have apost_deactivate hook, you have to actually rundeactivate to clean up the temporary environment or run the hook,respectively. It’s easy to forget and just exit the shell. Put thefollowing in ~/.bash_logout (or your shell’s equivalent file) toalways deactivate environments before exiting the shell:

  1. [ "$VIRTUAL_ENV" ] && deactivate