Now for some of my cows

zc.buildout is a system for managing development buildouts. Or in other words (mine): for deploying applications, for production usage or development work.

zc.buildout works by way of recipes where one or more recipes define what should be done and how. E.g. "install Zope-3, create an instance and make sure this and this egg is available on the python path". Usually a recipe needs some more information from the user to know where to install things or where to look for dependencies. This is specified in the buildout.cfg file.

I learnt using zc.buildout mainly by looking at other people's work (e.g. grok).

There you can see the specification for the buildout (in the buildout.cfg file) are part of project's hierarchy. So, you check out the project from, in this case, the Subversion repository and you have the project's sources and the specification to make a buildout for this project. You run the buildout command and voila, you have a running project set up.

This makes sense while developing on this particular project, but when you're deploying an application for production use, you do not necessarily want to checkout the sources for the project, since you probably already tagged the release version, uploaded the eggs for you project to some package index (e.g. the cheeseshop or some custom index) and created a buildout.cfg specifically for the deployment of this application.

For these situations I'm trying the following pattern "in the field":

In my project's hierarchy I add a sub directory called "deploy". This directory contains basically only a buildout.cfg. This buildout.cfg knows where to go and look for all the eggs it needs. Now you only have to get this "deployment" buildout.cfg onto the end user's machine and run it to set up the application.

todo: I need to have a look at http://svn.zope.org/zc.recipe.deployment/