Hi Jim, hi Christian, any further thoughts on this?
best regards florian On Fri, Apr 09, 2010 at 05:23:36PM +0200, Florian Friesdorf wrote: > On Fri, Apr 09, 2010 at 10:16:51AM -0400, Jim Fulton wrote: > > > 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 > > That would mean: > - 1 base.cfg > - 1 deploy.cfg > - 1 testenv.cfg > - 5 site-specific extending deploy.cfg > - 5 site-specific extending testenv.cfg > total: 13 files > > Site-specific information reside in two cfgs, which is error-prone. > > > In contrast to our current setup, with env var support, without > the need to duplicate information. > - 1 base.cfg > - 1 deploy.cfg > - 1 testenv.cfg > - 5 site specific cfgs > total: 8 files > > > Site-specific information could be factored out, as in the setup with > env var support: > > testenv-site-1.cfg: > [buildout] > extends = > testenv.cfg > site-1.cfg > > Information would not be duplicated but the amount of files increases to > 18. > > > Further we use a dev environment tailored for local individual > development in contrast to the testenv which is meant for the customer > to be kept up-to-date about the development, without e.g. PDBDebugMode. > With that dev environment the numbers are 18 (with site-specific info > in three places) or 23 vs. 9 files. > > This idea can be taken further to mass hosting in dedicated instances > but based on one buildout, or branches of one buildout that share the > majority of stuff. > > Other use cases coming to my mind: > - ip address for zope to listen on: instead of hard-coded 8080 or > 127.0.0.1:8080, you can have ${env:MYPROJECT_LISTEN} and people being > involved in several projects can choose in order to have several > buildouts running in parallel > - location of the Data.fs: I like to have the Data.fs outside of the > buildout dir for development, which enables the use of 'git clean > -xdf', i.e. wiping everything which is not tracked. > > > I like the idea of the need to configure the name of the environment > section: > [buildout] > environment=env > extends = ${env:...} > > At the time the extends are processed, the whole buildout section is > already read into the options dict, so configuration of the name of the > environment section is easily possible and can be used to trigger the > substitution code: > if extends: > envsecname = options.get('environment') > if envsecname: > # do variable substitution like in my patch > # if no environment is specified nothing changes > # continue normally > > I would not pop() the options, so the name of the environment section > can be queried by other parts of buildout. Likewise, extends could not > be pop()'ed - both then would need to go onto a list, which buildout > checks, in order not to complain about them being unused. > > > If I could get commit acces to svn.zope.org, I would further work on > this in a separate branch, more effective than via patches. Committer > agreement I can fax/email. I am not committing to branches that don't > belong to me, without prior consultation. So far I have commit access to > the plone repo, which might be meaningless or at least a minor sign of > credibility. > > > I hope I could clarify the usefulness of env var support. > > florian > > -- > Florian Friesdorf <f...@chaoflow.net> > GPG FPR: EA5C F2B4 FBBB BA65 3DCD E8ED 82A1 6522 4A1F 4367 > Jabber/XMPP: f...@chaoflow.net > OTR FPR: 9E191746 213321FE C896B37D 24B118C0 31785700 > IRC: chaoflow on freenode,ircnet,blafasel,OFTC > _______________________________________________ > 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 ) -- Florian Friesdorf <f...@chaoflow.net> GPG FPR: EA5C F2B4 FBBB BA65 3DCD E8ED 82A1 6522 4A1F 4367 Jabber/XMPP: f...@chaoflow.net OTR FPR: 9E191746 213321FE C896B37D 24B118C0 31785700 IRC: chaoflow on freenode,ircnet,blafasel,OFTC _______________________________________________ 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 )