> 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"...
> 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
> 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
> And sometimes it is useful
> to link an existing instance to a new buildout by updating some paths in
I don't understand this. Please explain more...
> Or to create several instances based on one buildout.
>> Interesting. I never noticed that... Hopefully that change will make it
>> into Zope 2.12 final?
> Yes. I made that change on the 2.12 branch as well.
>> 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:
> Or did you mean something else?
I meant I nicer way of passing in the location of 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...
>>> 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
Sure, I can't imagine it's a particularly hard problem, it's just not
one the I'm interested in solving...
Simplistix - Content Management, Batch Processing & Python Consulting
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -