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”.
$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:
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:
mkipythonconfig is the snippet above.
Add an alias to maintain your environment variables
I got really sick of
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
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