[Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like

[Philipp von Weitershausen]

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