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 > _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
