[Distutils] zc.buildout

Martin Aspeli optilude at gmx.net
Wed Aug 8 23:13:02 CEST 2007


Miles wrote:
> Hi,
> 
> We have some a zc.buildout-based deployment system, and we're looking at 
> how we can make the process slightly easier for moving between 
> development, testing and production environments.
> 
> I was wondering if others have a pattern for setting up a buildout in 
> this way?  I am imagining that this is better done by running the 
> different steps, but putting the outputs in different locations (e.g. 
> for testing, put apache configurations in some directory in the test 
> tree), rather than trying to selectively run steps (e.g. for testing, i 
> do not want apache configurations set up).  Is there a useful 
> buildout.cfg pattern that covers this?
> 
> Also, one other use-case that we've got is to be able to group parts 
> together into sets.  So, for example, I'd lie to be able to do something 
> like:
> 
> [buildout]
> parts = awstats
> 
> [awstats]
> parts = awstats-download apacheconf-install crontab-install
> 
> which would tell buildout to run the three parts listed, rather than 
> remembering all 3 specific parts in the parts list.  The advantage being 
> to ensure the bits are always run together.
> 
> Has anyone done anything like this at all?

I'm not sure it meets your needs exactly, but you can have one buildout 
file depend on another. In this case, they are "merged":

[buildout]
base = basics.cfg

...

Here, you get all of basics.cfg, and subsequent parts of the file can 
override or extend those settings. Sections with the same name are 
merged as well, so you can override and merge parts of a part, as it were.

So, for example, you may have a buildout.cfg that has your normal 
development setup, and a deployment.cfg that is based on this, but turns 
off debugging and adds deployment stuff like Apache. Use -c when running 
./bin/buildout to specify an alternate file.

Martin

-- 
Acquisition is a jealous mistress



More information about the Distutils-SIG mailing list