[Zope-dev] Re: ploneout - Or how using zc.buildout for a common
Zope2 project might look like
Philipp von Weitershausen
philipp at weitershausen.de
Tue Jan 23 18:12:55 EST 2007
On 23 Jan 2007, at 23:56 , Martin Aspeli wrote:
> Philipp von Weitershausen wrote:
>
>> This is awesome, and by that I don't mean the fact that we have a
>> plone buildout, but that we actually have Zope 2 recipes for
>> buildout. I hope they can be moved to svn.zope.org for further
>> development to benefit the whole Zope 2 community.
>
> I believe this is just a matter of contrib agreements being sorted
> out (Hanno?). I guess I need to get mine sorted out as well if I'm
> going to keep working on this when it moves... :-/
Great.
>> I also see that workingenv was abandoned. That's very good to hear
>> because buildout has a lot of machinery for installing eggs
>> already, it would just've been duplicated with workingenv...
>
> Workingenv made it more complex than it needed to be (or buildout
> did, depending on which perspective you look at it from). I believe
> Hanno wanted to rescue the recipe in case others found it useful,
> but it's not used for now.
>
>> gocept's Zope 3 instance recipe actually installs a script into
>> the top-level bin directory, so you can do:
>> $ bin/buildout
>> ...
>> $ bin/instance fg
>> Where 'instance' is the name of the instance configuration section
>> in buildout.cfg. So, if you have multiple instances, you can start
>> them all with according scripts from 'bin'.
>> It'd be really cool if z2c.recipe.zope2instance would do the same.
>> To be frank, I think having to mess around in 'parts' sucks. I
>> would even argue that app data like logs, databases, etc.
>> shouldn't be in 'parts' either. You should be able to delete
>> 'parts' and lose nothing (disclaimer: this is my view, not sure
>> how "Buildout Jim" see it ;)).
>
> I would tend to agree, especially since buildout has a tendency to
> delete things in parts/ in any case (or rather, recipes do).
>
> I don't think it'd be hard to make such a script (perhaps more
> difficult to make it be cross-platform, we really need a champion
> for all this on the windows platform!).
>
> It'd be trivial to change the z2c.recipe.zope2filestorage recipe to
> use a different directory. We probably need another "top level"
> directory though, because the part name is used as the directory
> name. Again, we just need a steer on what's recommended practice.
> For example, we could use ${buildout_home}/var/${part_name}...
Right. What I'm saying is that this should be the default. Sensible
defaults is sometimes all it takes to get something adopted. Just
look at that Plone thang ;).
On another tangent, I'd like to direct your attention to grokproject
(http://cheeseshop.python.org/pypi/grokproject). It's an idiot-proof
way of setting up new buildouts that have grok and a custom
development package preconfigured. It uses paste.script to create a
raw buildout directory with a bunch of default and boilerplate
things. It then bootstraps the buildout and builds the buildout. It's
not rocket science, but it's made the whole "how do I get started
with grok" thing a lot easier.
I could envision that buildout-based deployment for end users (who
don't necessarily tweak buildout.cfg etc.) could look a lot like
that. Perhaps it's worth exploring this in a general manner, so that
grok, Plone, and other zc.buildout consumers could share the same
platform for end-user installation. I see some common goals to
tackle, for example:
- off-line installation (bootstrapping a buildout from already packaged
eggs instead of downloading from the internet)
- a Windows installer
- ...
Philipp
More information about the Zope-Dev
mailing list