If you work with multiple Python projects that use different versions of things virtualenv is indispensable. It allows you to have totally isolated execution environments for different projects. I'm also using Doug Hellmann's virtualenvwrapper, which wraps up a few virtualenv commands and gives you some hooks you can use. When I start a new project it looks something like this:
$ git checkout some_repo
$ cd some_repo/
$ mkvirtualenv project_name
The first two steps are probably self explanatory. What mkvirtualenv does is to a new virtual environment, and activate it. I also have a hook set up with virtualenvwrapper to install the latest development version of pip, as well as ipython and ipdb. pip is a tremendous asset to this process. It has a requirements file that makes it very easy to keep track of all the dependencies for a given project, plus pip allows you to install packages out of a version control system which is tremendously useful.
When I want to work on an existing project all I need to do is:
$ workon project_name
This activates the environment for that project. Now the PATH prioritizes stuff installed into that virtualenv, and my Python path only has stuff installed into this virtualenv. I can't imagine what my job would be like without these tools, if I had to manually manage the dependencies for each project I'd probably go crazy within a week. Another advantage is it makes it easy to test things against multiple versions of a library. I can test if something works on Django 1.0 and 1.1 just by switching which environment I'm in.
As promised tomorrow I'll be writing about an optimization that just landed in Unladen Swallow, and I'm keeping Monday's post a secret. I'm not sure what Tuesday's post will be, but I think I'll be writing something Django related, either about my new templatetag library, or the state of my multiple database work. See you around the internet.
Have you tried using zc.buildout? Seems like a perfect fit here.
ReplyDeleteAs Adomas said, this is a pretty good fit for zc.buildout where my workflow is, at worst:
ReplyDelete$ svn co some_project
$ python2.6 bootstrap.py
$ bin/buildout
...which could just as easily be wrapped up into a "workon" script :-)
The problem with zc.buildout is that it relies on setuptools, so you're still attached to easy_install. Virtualenv + Virtualenvwrapper + PIP make a slick combination.
ReplyDelete