If you’re doing any development in Python, odds are you’re using virtualenv. And if you’re using virtualenv, odds are you’re using virtualenvwrapper. I came up with a few tricks to make my life easier, and I thought I ought to share them. And as a disclaimer: although I am obsessed with discovering best practices, these are definitely not. So I’m adding a new category called “Meh Practices”.
Set an $IPYTHONDIR environment variable.
According to the IPython documentation, IPython stores settings in a profile, and it looks for that profile in $IPYTHONDIR. So in my global virtualenv postactivate, I have:
export IPYTHONDIR=$VIRTUAL_ENV/.ipython
Now why would anyone want a separate profile for every virtualenv? I do this so every virtual’s IPython gets its own history database. I also used to run IPython 0.10.X and 0.11.X side by side, and the two had incompatible profile formats. All my tools support the new IPython so this isn’t an issue for me anymore, but I still do it for the separate history.
Maintain the same IPython configuration for every profile
Because now I’m running around with N IPython profiles with N configurations when I really only want 1 configuration, I symlink all the profile configurations from a master one I keep in source control. The gist of it looks like:
DST=$IPYTHONDIR/profile_default
SRC=$HOME/.dotfiles/.ipython/ipython_config.py
mkdir -p $DST
cd $DST
ln -s -f $SRC
But my actual one currently looks like this and I run it in my global postmkvirtualenv, which now looks like:
IPYTHONDIR=$VIRTUAL_ENV/.ipython
mkipythonconfig
Where mkipythonconfig is the snippet above.
Add an alias to maintain your environment variables
I got really sick of cdvirtualenv then vi bin/postactivate, so in my postactivate, I have this line:
alias vivirtualenv="$VISUAL $VIRTUAL_ENV/bin/postactivate"
in my virtualenv’s postactivate. Now when I need to edit my postactivate, it’s a few tab complete-able keystrokes away. I stole the naming convention from visudo, and I tried naming it vipostactivate, but I think vivirtualenv is just so catchy. Now if your immediately reaction is to make a comment telling me I should just use autoenv; too bad, I already thought about that. Right now, issue#28 is preventing me from adopting autoenv. I also can’t go around adding .env to the .gitignore of collaborated projects. And there’s one project I know of where the Procfile for foreman is not in the project root. #everythingisterrible
Use setvirtualenvproject
I don’t take advantage of virtualenvwrapper’s mkproject, nor do I really know what to do with them, but there is one thing I do use from that… setvirtualenvproject. I never use mkproject because I rarely name my projects and virtualenvs the same, and I haven’t bothered to set up any project templates. But I am lazy, and I like how if you tell virtualenv that your current working directory is the project root using setvirtualenvproject, every time you workon it, you’ll automatically cd into it. But what if you don’t want that to happen? You can jump back to the directory you were just in with cd -. For me, the extra time it takes to go back is more than made up by all the time saved not having to cd in.
So putting everything together, I have a makefile for bootstrapping a new install so virtualenvwrapper and IPython are set up the way I like. It may seem like I have to do a lot of work to get up and running, but I’ve got it down to one make now.