On Thu, Apr 8, 2010 at 9:32 AM, Florian Friesdorf <f...@chaoflow.net> wrote: > On Thu, Apr 08, 2010 at 02:24:53PM +0200, Christian Theune wrote: >> Hi, >> >> On 04/08/2010 12:59 PM, Florian Friesdorf wrote: >> > On Thu, Apr 08, 2010 at 08:56:18AM +0200, Christian Theune wrote: >> >> On 04/08/2010 04:27 AM, Florian Friesdorf wrote: >> >>> environment variable support for zc.buildout, including extends! >> >>> >> >>> https://bugs.launchpad.net/zc.buildout/+bug/557769 >> >>> >> >>> works for me so far >> >> Actually the env recipe was more of a hack to get going and then we >> forgot to propose getting it into buildout. >> >> OTOH handling it as a recipe allows for some other nice tricks, e.g. >> overriding by extensions. >> >> Maybe a specialised part-name, like versions would be helpful so that >> buildout could pre-populate that part during initialisation and then >> allow configurations to override individual values. > > that would be nice indeed, but again would not work for extends > > We currently use it for 5 very similar sites that share one repository > but use 5 checkouts of it: > > base.cfg > [buildout] > parts = instance > > develop = ... > eggs = ... > zcml = ... > > [instance] > ... > > > site-1.cfg > [buildout] > eggs += > zcml += > > > testenv.cfg > [buildout] > extends = > base.cfg > ${env:site}.cfg > > <stuff for testenv> > > > deploy.cfg > [buildout] > extends = > base.cfg > ${env:site}.cfg > > <stuff for deploy> > > > % site=site-1 ./bin/buildout -c deploy.cfg
Your extends usage seems a bit convoluted. Why not just have: - deploy.cfg extend base.cfg - site1-1.cfg etc extend deploy.cfg Then you'd just: % ./bin/buildout -c site-1.cfg Jim -- Jim Fulton _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )