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

[yuppie]

Hi Chris!


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

Of course buildout in general is used in many ways and often for setting 
up instances.

>> is used to set up instances. And while I see that using buildout for 
>> setting up everything in one step has some advantages, it's not the best 
>> pattern for all use cases.
> 
> So tell us where it's not best rather than just asserting that such a 
> use case exists ;-)
> 
>> mkzopeinstance helps to draw a line between software and data. 
> 
> No it doesn't. Plenty of software can live in an instance.
> IMNSHO, buildout does a *better* job of drawing a line between software 
> and data...
> 
>> that's important for distributors who want to distribute generic 
>> software, not user specific instance setups. 
> 
> Distributors just want a tarball or similar, let them use 
> zc.sourcerelease and have a slightly different buildout.cfg, or even 
> default.cfg, which uses that tarball as the source of eggs rather than 
> PyPI...
> 
>> 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...
> 
>> 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. There is nothing 
wrong about using buildout that way, but maybe it's wrong to make it the 
only supported way.

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. And you might have local changes in that buildout. These 
buildouts are more 'software' than 'instance'. Maybe with that scenario 
my assertions make more sense to you?

>>> Cool. If only the zope2 egg could expose these now, it would make the 
>>> buildout.cfg simpler... just the matter of passing in the config. I 
>>> wonder if anyone can think of a nicer way of doing that?
>> runzope and zopectl are defined as entry points:
>> http://svn.zope.org/Zope/tags/2.12.0b4/setup.py?rev=102515&view=auto
>>
>> Or did you mean something else?
> 
> 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. And if you use mkzopeinstance the command line option seems to 
be the right way to specify zope.conf.

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

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


Cheers,

	Yuppie