[Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal

[Chris Withers]

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