easy_install: virtualenv or hard maintenance

At Except we have over a dozen computers running Ubuntu being used as developer workstations. Most of our developers work in Python, so often there is a real need to install cutting-edge software, and too often the instructions go something like

$ sudo easy_install <package>

and down that road lies madness.

The problem is that easy_install by default drops things into /usr/lib/pythonX.Y, which messes up the packaging system, and also interacts badly with other software needing conflicting versions of the same libraries installed. Yes, it happens all the time when you’re developing: often different Plone or Zope versions depend on different libraries, or you install twisted-based applications via the package manager that use library versions that conflict with development, or all kind of other ugly stuff (DLL hell, anyone?).

Another problem is that your users are suddenly unable to work except from the box where they installed the software, so if you have a visiting geek from elsewhere using that computer, you need to get creative with ssh to get work done. And you know the visitor will dutifully turn off the computer when she leaves, in the middle of your work. Or that reinstalling the machine due to a dead disk now involves more than the work of the ad-hoc sysadmin; it means lost productivity for the developer, too.

One workaround is to download Python and set it up in your home, so you have your own python, your own libraries, everything securely installed in a project-specific location. This is the other end of the scale, and while it does work, it’s a terrible pain to keep everything updated (gentoo, anyone?).

The right way to do it, in that it balances the need for autonomy with the need for expediency, is to use virtualenv to provide for having customized, lightweight Python installations without having to grow your own. One thing that I find funny (in the what are they thinking?!? kind of way) is that virtualenv’s installations instructions are… yes, you guessed it:

$ sudo easy_install virtualenv

Fortunately you can download virtualenv and use it directly,

$ cd /tmp/
$ wget http://pypi.python.org/packages/source/v/virtualenv/virtualenv-1.1.tar.gz
$ echo '8931b66dbb799120583dd107aab2fa89  virtualenv-1.1.tar.gz' | md5sum --check
virtualenv-1.1.tar.gz: OK
$ tar xzf virtualenv-1.0.tar.gz
$ cd virtualenv-1.1
$ python virtualenv.py ~/src/project/env/
New python executable in .../env/bin/python
Installing setuptools.............done.
$ cd ~/src/project/env/
$ . bin/activate

The last two lines are all it takes now to be able to do

(env)$ easy_install package

and have package installed inside your project’s hierarchy. Also, python is now the python in that hierarchy, and all your libraries come from there by default, so you can override the system-installed ones very easily. With this, the buildout starts to make a lot more sense in a multiuser context. In fact, it’s such a powerful combination I can’t think of any reason to carry on doing things the old way.

Chocamos! »« Let’s discuss the matter further » Using Zope Adapters