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