yuppie wrote: >>> You ripped my sentence out of context. We were talking about Zope 2.12. >>> And Zope 2.12 currently doesn't use buildout for setting up instances. >> Sure it does. I've published the recipe. There's no more needed than that... > > Your recipe is not published as part of Zope 2.12.
I'm not sure it needs to... > And it doesn't work > on Windows. Have you tried it? >> Nope. As I said, The "Zope 2.12" software will never be in such a >> buildout, just used by it. As such, the "egg cache" wherever and however >> you have it becomes the "Zope 2.12" software... Anything in the buildout >> is "software" that is local to that instance, like Products or External >> Methods used to be in days of old... > > Are you ignoring the fact that buildouts with several dev eggs exist? Or > do you define all dev eggs as local to the instance? I don't really see what you're driving at here... "dev eggs" are just lines in {buildout:develop}, where they point to doesn't matter so I don't know what you mean by "local to the instance"... > For development I regularly use one dev buildout with several different > test instances. Can you post an example buildout.cfg, and what your instances look like, since I don't reall understand what you're doing... > The dev eggs are local to my dev buildout, but not local > to the test instances. What does this actually mean? For me, a "dev egg" is usually just an svn checkout, specified in {buildout:develop}. For me, they're never usually in any "buildout", unless the package itself is buildout-driven and I'm actually developing it, but that has nothing to do with my test instances... That said, I often use a few "dev eggs" that aren't buildout driven at all, so I really fail to see your point... >>>> I meant I nicer way of passing in the location of zope.conf... >>> If you create the instance in the same step your solution doesn't look >>> that bad. >> I don't know what you mean by this... > > You propose to create the entry point and the instance in the same step. What is "the instance" you're referring to here? > And you have these lines in your buildout.cfg: > > initialization = > import sys > sys.argv[1:1] = ['-C','${buildout:directory}/etc/zope.conf'] > > Why are you not happy with that solution? It feels icky... >>> Exactly. But if we always use the same Python, why do we have to specify >>> it in several places? >> Huh? You don't... > > Your buildout.cfg creates an interpreter entry point 'py'. Your > zope.conf.in specifies "python $INSTANCE/bin/py". That would never need to be changed be anyone using a buildout-based instance. If buildout was blessed as "the right way", it could disappear into a default and nto even need to be included. > But the zopectl entry point already contains all the information it > needs. runzope doesn't depend on 'py'. Why does zopectl have to look up > the interpreter path in zope.conf und use 'py'? I dunno, ask whoever wrote zdaemon ;-) If it's not specified, it just uses "python", which won't have the buildout's eggs available. cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk _______________________________________________ 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 )