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


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

- ...


Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to