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

[Chris Withers]

yuppie wrote:
>> yuppie wrote:
>>> Currently buildout is just used to set up the software. 
>>
>> Wrong. The buildout I posted, which uses no fancy recipes, sets up an 
>> instance. The egg cache, as such, is "the software"...
> 
> 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...

>>> And sometimes it is useful to link an existing instance to a new 
>>> buildout by updating some paths in instance/bin. 
>>
>> I don't understand this. Please explain more...

Still waiting for you to explain this more...

>>> Or to create several instances based on one buildout.
>>
>> Why?
> 
> I guess the scenario you have in mind is a lightweight buildout that 
> just contains some .cfg files describing the instance. 

Indeed, or any software that's local to that instance and isn't 
distributed as an egg.

> There is nothing 
> wrong about using buildout that way, but maybe it's wrong to make it the 
> only supported way.

Why? It should be fairly trivial to make mkzopeinstance a script that 
unpacks bootstrap.py and constructs the skeleton directories, zope.conf 
and buildout.cfg. I really don't see what more is needed than that?

> The scenario I have in mind is a buildout that contains several 
> development eggs. In that case it is expensive to update and rebuild a 
> buildout. 

No it isn't.

> And you might have local changes in that buildout. 

What does that have to do with anything?

> These 
> buildouts are more 'software' than 'instance'. Maybe with that scenario 
> my assertions make more sense to you?

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...

>> 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...

>>>>> we can make it unnecessary to specify the interpreter. 
>>>> When runzope and zopectl are built by buildout, this is already the 
>>>> case... One python is used for both...
>>> No. Currently you also need 'zopepy' (or 'py' in your case). 
>>
>> They're all the same python...
> 
> Exactly. But if we always use the same Python, why do we have to specify 
> it in several places?

Huh? You don't...

>>>>> 4.) How do you create zopeservice.py for Windows?
>>>> What's Windows? Seriously though, I haven't needed to run Zope 2.12 
>>>> on Windows, so I don't know...
>>> But we have to support Windows. And I was able to get zopeservice.py 
>>> running with mkzopeinstance. *If* we decide to use buildout the way 
>>> you propose, someone has to figure out how to create zopeservice.py 
>>> without mkzopeinstance.
>>
>> Sure, I can't imagine it's a particularly hard problem, it's just not 
>> one the I'm interested in solving...
> 
> That makes two of us. If nobody wants to do the work, your proposal is 
> moot.

*sigh* By all means, please do go ahead and make more work for yourself ;-)

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk