Sijainti: Pääsivu / From the trenches, programmatically / Mixing site packages into buildout

Mixing site packages into buildout

Sometimes 'corrupting' the buildout can be convenient.

With Debian Wheezy released, support for Python 2.7 is finally available out of the box.

Besides Python itself, Debian provides a bunch of third-party libraries, nicely packaged and ready to use. One such package is lxml, provided by the 'python-lxml' Debian package. No longer does it need to be compiled from source. Granted, the initial lxml version of provided by Debian stable is 2.3.2 which is somewhat old by now. It's likely that various alternative package sources will soon enough provide newer versions though, given this is all open source, and any friendly soul is welcome to build a Debian package out of a newer version of lxml.

While this is all nice and dandy, many a pythonista nowadays uses (zc.) buildout for deploying software. As zc.buildout is used (among other things) to isolate a local environment from the (global) system environment, mixing in site packages goes against the idea of buildout, somewhat.

However, it is sometimes desirable to do that, such as when the platform provides tested, easy-to-install built-in packages. A convenient means to that end is the collective.recipe.mockedeggs recipe:

[buildout]
parts += mocked
[mocked]
recipe=collective.recipe.mockedeggs
mocked-eggs =
   lxml = 2.3.2

Basically, what the mockedeggs recipe does is fool buildout into believing that certain system packages have been installed as eggs.

For detailed usage instructions and caveats, see the recipe docs.

Tweets