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/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
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -