[Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
Chris Withers
chris at simplistix.co.uk
Mon Sep 7 07:35:03 EDT 2009
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
More information about the Zope-Dev
mailing list