virtualenvwrapper tips and tricks

I’ve seen a few people talking about how they use virtualenvwrapper on twitter, including some links to customizations like these aliases from Holger Krekel.

If you have some tips of your own, I’d appreciate a link in the comments here. Once I have a few collected, I’ll pull together some of the interesting ones and add them to the documentation.

So, how do you use virtualenvwrapper?

http://www.blogger.com/profile/16779944428406910187 Wrathematica

This comment has been removed by the author.
http://www.blogger.com/profile/16779944428406910187 Nat

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

in postactivate:

PS1=”$_OLD_VIRTUAL_PS1″
_OLD_RPROMPT=”$RPROMPT”
RPROMPT=”%{${fg_bold[white]}%}(env: %{${fg[green]}%}`basename \”$VIRTUAL_ENV\”`%{${fg_bold[white]}%})%{${reset_color}%} $RPROMPT”

and in postdeactivate:

RPROMPT=”$_OLD_RPROMPT”

(I’m sure the line breaks are gonna get messed up somehow, the first one should only be 4 lines)

Not any huge functionality, I know, but I find it a lot nicer looking that the default. Adjust colors according to your own personal tastes or environment.

I also added the command ‘rehash’ to both of the above files, as I was having some problems with zsh not picking up the new paths immediately. That’s probably just some stupid setting in my environment, though.
http://www.blogger.com/profile/02454160645313349401 peterbe

(not my idea originally but I can’t find the original “blog” about it but his name was Justin)

Inside the relevant directories, create a file called `.venv` and in it write what you would otherwise feed as first parameter to the workon command. Then put this in your .bashrc:

has_virtualenv() {
if [ -e .venv ]; then
workon `cat .venv`
fi
}
venv_cd () {
cd “$@” && has_virtualenv
}
alias cd=”venv_cd”

Then you get switched onto the right environment simply by going into its directory. Extremely nifty!
http://becomingguru.com/ becomingguru.com

These simple recommended ones are the only ones I use:

export WORKON_HOME=/home/ub/.virtualenvs
source /usr/local/bin/virtualenvwrapper_bashrc
export PIP_VIRTUALENV_BASE=$WORKON_HOME
http://www.blogger.com/profile/02618224969192901883 James

In the postmkvirtualenv script I have the following to create a directory based on the project name, add that directory to the python path and then cd into it:
proj_name=$(echo $VIRTUAL_ENV|awk -F’/’ ‘{print $NF}’)
mkdir $HOME/projects/$proj_name
add2virtualenv $HOME/projects/$proj_name
cd $HOME/projects/$proj_name

In the postactivate script I have it set to automatically change to the project directory when I use the workon command:
proj_name=$(echo $VIRTUAL_ENV|awk -F’/’ ‘{print $NF}’)
cd ~/projects/$proj_name
http://www.blogger.com/profile/01892352754222143463 Doug Hellmann

Great tips, everyone! Keep them coming!

@Nat – Cool prompt trick!

@peterbe – I think that was from Justin Lily’s helper post: http://justinlilly.com/blog/2009/mar/28/virtualenv-wrapper-helper/
http://www.blogger.com/profile/01892352754222143463 Doug Hellmann

@James – I think you could use basename instead of that awk command to convert $VIRTUAL_ENV to the environment name. Do you use a postrmvirtualenv hook to remove the project directory?
http://www.blogger.com/profile/16779944428406910187 Nat

Also, in addition to what becomingguru said, this line is key:

export PIP_RESPECT_VIRTUALENV=true

That makes pip detect an active virtualenv and install to it, without having to pass it the -E parameter.

It’s not really a virtualenvwrapper tip per se, but it is an enormous part of what makes the whole pip/virtualenv(wrapper) ecosystem a complete no-brainer for me.
http://rizumu.myopenid.com/ rizumu

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

✈ cat postmkvirtualenv
#!/usr/bin/env bash
curl -O http://python-distribute.org/distribute_setup.py
python distribute_setup.py
rm distribute_setup.py
easy_install pip==dev
pip install Mercurial

Then I have a pip requirement file with my dev tools.
✈ cat developer_requirements.txt
ipdb
ipython
pastescript
nose
http://douglatornell.ca/software/python/Nosy-1.0.tar.gz
coverage
sphinx
grin
pyflakes
pep8

Then each project has it’s own pip requirement file for things like PIL, psycopg2, django-apps, numpy, etc.
http://www.blogger.com/profile/02618224969192901883 James

@Doug thanks for the tip on basename, I didn’t know about that command.

I don’t have it remove the project directory using the postrmvirtualenv hook. I thought about doing that, but decided I’d prefer the safeguard of having to manually delete the project dir.
http://www.blogger.com/profile/01892352754222143463 Doug Hellmann

@James – Playing it safe makes complete sense to me.
http://www.blogger.com/profile/10879711379090472478 mae

I posted mine in a previous blog post can’t remember if it was by Doug or someone else.

This is supposed to be executed after workon: that is as a postactivate hook. It basically overrides cd to know about the VENV so instead of doing cd to go to ~ you will go to the venv root, IMO very handy and I can’t live without it anymore. if you pass it a proper path then it will do the right thing.

cd () {
if (( $# == 0 ))
then
builtin cd $VIRTUAL_ENV
else
builtin cd “$@”
fi
}

cd
http://www.blogger.com/profile/01558084887128300346 Quentin

@James and @Doug, you can use bash parameter expansions without going to sed, awk, or basename, saving an exec (which is almost a ludicrous notion now with 3Ghz processors running in 4G of space).

proj_name=${VIRTUAL_ENV##*/}

Do “man bash” and search for “##” for more info. I esp. remember this one because most of my bash utilities start with

PROG=${0##*/} # get prog name from $0

– Quentin
http://www.blogger.com/profile/17141199633387157732 harry.marr

I’ve written a bash function that automatically calls “workon” when you cd into a Git repository, and deactivates it when you leave it.

The full details and the code are on my blog.