They are tools for working with the deployed modules. So for instance, when I have a library and I want to release it, I have to create a tag in the version control. I have to update the news file, run some tests, change some metadata in setup.py, etc. Maybe I have to update some gettext catalogs, etc. These are the kinds of tools I am talking about.
What zc.buildout and buildit do comes after that. After you have does all these code maintenance tasks, they help you use the code in a real deployment.
Hrm, I think around is more how zc.buildout fits in the picture. In combination with find-links it can be a great way to maintain a consistent set of the kinds of tools you could run from make; but all packaged up for python. I think this use overlaps with workingenv. One of my pet gripes with setup.py has nothing to do with its utility. I like my build configuration to be declaritive. placing entry_points, version, and all sorts of other build facts in setup.py makes it a pain to consume that data else where. .egg-info is only available after the build has run. There does not seem to be a 'best practice' for sourcing entry-points etc from a seperate, declaritive, file. setup.cfg maybe but its not what I use.
A couple of buildout recipes I've been fooling around with: http://svn.wiretooth.com/svn/open/rsb_sourcesvn/trunk/ checkout sources from svn into a build out http://svn.wiretooth.com/svn/open/rsb_setupdevelop/trunk/ wraps zc.recipe.egg:scripts to do the equivelent of 'python setup.py develop' Illustrate the way my setup.py usage is going these days.
And then I tend to have a 'toolbox' buildout that pulls in this config http://svn.wiretooth.com/svn/open/share/zc.buildout.cfgs/python-development-tools.cfg
Using buildouts 'config from url' trick.
All that said, your OP is spot on, its not make we are all missing.# robinbryce