[Distutils] zc.buildout

[Miles]

Thanks for the info.  I've got the extends stuff working nicely for 
having a "library" of tasks, and then project-specific bits in a 
buildout, but haven't got it structured for specific different setups 
yet (testing, deployment, devel, etc).

I just discovered how to turn "off" the recipe used for a part when 
overriding and just provide configuration (e.g. for dev, don't build 
python, just provide a location for the one already installed) so that 
removes quite a bit of repetition.

Thinking about it a bit more, what originally sparked off the post was a 
need to run some steps as root (e.g. to install startup scripts in 
/etc/init.d), and others as a different user (zope files owned by the 
zope user).

At the moment, we tackle this by (for example):

$ su
$ bin/buildout -c buildout-root.cfg
$ exit
$ su zope
$ bin/buildout -c buidlout-zope.cfg
...

However, this starts to get complicated as more users are involved! 
Plus, each step cannot easily use the configuration from a previous one, 
so there's some repetition.

Do you have a pattern that covers this at all?

Miles


Martin Aspeli wrote:
> 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
>