Thank Cthulhu Almighty, I'm free!
Nov. 25th, 2010 09:18 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
le_bebna_kamniI am finally free of the tyranny that is virtualenv. Don't get me wrong -- it's marvelous tool for working in multiple Python development environments that all have different requirements. For those of you not familiar with virtualenv it does all these wonderful things:
But it creates a slew of virtualenv folders that are hard to manage and can't be moved except at great cost to time and sanity (all hail Cthulhu). It also creates that annoying trail of folders that looks something like 'foo/foo/foo' (virtualenv/Django project/Django app)*.
In steps virtualenvwrapper. This beautiful tool puts all your virtualenvs into your home directory into a hidden folder that you never have to think about unless you want to do some special configuration. Making a virtualenv using wrapper is a simple 'mkvirtualenv --no-site-packages [project name]', and then you can place your actual project directory anywhere you want (and easily move it later without breaking it). To work in your virtualenv, you simply type 'workon [project name]' from any directory, and you're instantly in your Python environment.
And speaking of special configuration... you can create scripts to run before and after you make, activate, deactivate, or remove a virtualenv. And you can configure these globally or on a per-project basis. I'm fairly modest with my scripts right now -- a simple cd into the project directory when I activate, then a cd back to wherever I started from. To do this, you need to edit the following two files:
~/.virtualenvs/[project name]/bin/postactivate:
Before you can make your first wrapped virtualenv, you have to create a .virtualenv folder to house your many environments; otherwise virtualenvwrapper will complain at you. This is probably the biggest shortcoming (and only shortcoming, so far for me) that virtualenvwrapper has. Why it can't attempt to auto-create the folder and *then* complain if it can't, is beyond me. Fortunately you only have to deal with this problem once.
You'll need to source the virtualenv.sh script before you can use any commands. For those Ubuntu users out there, the easiest way for this to happen automagically is to edit your .bashrc file to have the following line:
---------------------------------------------
* Okay, you can name the folders foo-env/foo-proj/foo, but that still annoys me after awhile, especially if you have long project names to begin with.
** For those of you who don't know, I now have a new job doing Python development. I'm really *squee*-ed about it. Unfortunately it involves moving halfway across the country, in exactly two weeks. Right now I'm telecommuting, planning a move, and trying to finish the contract work I picked up here in Michigan to tide me over until I found a job. Hence why I'm working (and procrastinating) on a holiday. :)
- allows you to install all your dependencies without being root
- lets you have a clean working environment with only the dependencies you need -- you don't have problems with conflicting dependencies or giving your project to someone and forgetting to mention a dependency because you previously had it installed on your machine
- easy uninstall -- just delete the folder
- adds to your geek cred
But it creates a slew of virtualenv folders that are hard to manage and can't be moved except at great cost to time and sanity (all hail Cthulhu). It also creates that annoying trail of folders that looks something like 'foo/foo/foo' (virtualenv/Django project/Django app)*.
In steps virtualenvwrapper. This beautiful tool puts all your virtualenvs into your home directory into a hidden folder that you never have to think about unless you want to do some special configuration. Making a virtualenv using wrapper is a simple 'mkvirtualenv --no-site-packages [project name]', and then you can place your actual project directory anywhere you want (and easily move it later without breaking it). To work in your virtualenv, you simply type 'workon [project name]' from any directory, and you're instantly in your Python environment.
And speaking of special configuration... you can create scripts to run before and after you make, activate, deactivate, or remove a virtualenv. And you can configure these globally or on a per-project basis. I'm fairly modest with my scripts right now -- a simple cd into the project directory when I activate, then a cd back to wherever I started from. To do this, you need to edit the following two files:
~/.virtualenvs/[project name]/bin/postactivate:
export ORIGDIR=`pwd`~/.virtualenv/postdeactivate:
cd /path/to/project/folder
cd $ORIGDIR
Notes on configuration:
Before you can make your first wrapped virtualenv, you have to create a .virtualenv folder to house your many environments; otherwise virtualenvwrapper will complain at you. This is probably the biggest shortcoming (and only shortcoming, so far for me) that virtualenvwrapper has. Why it can't attempt to auto-create the folder and *then* complain if it can't, is beyond me. Fortunately you only have to deal with this problem once.
You'll need to source the virtualenv.sh script before you can use any commands. For those Ubuntu users out there, the easiest way for this to happen automagically is to edit your .bashrc file to have the following line:
source /usr/local/bin/virtualenvwrapper.shI think it's .bash_profile for Mac users -- double-check the install location of virtualenvwrapper.sh; Windows users, you're on your own. ;)
---------------------------------------------
* Okay, you can name the folders foo-env/foo-proj/foo, but that still annoys me after awhile, especially if you have long project names to begin with.
** For those of you who don't know, I now have a new job doing Python development. I'm really *squee*-ed about it. Unfortunately it involves moving halfway across the country, in exactly two weeks. Right now I'm telecommuting, planning a move, and trying to finish the contract work I picked up here in Michigan to tide me over until I found a job. Hence why I'm working (and procrastinating) on a holiday. :)
