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

Martin Aspeli optilude at gmx.net
Thu Jan 25 15:45:26 EST 2007

Philipp von Weitershausen wrote:

> The point is that buildout *already* handles eggs. There's really no 
> point for having an extra layer on top of buildout. The zc.recipe.egg 
> recipe can install any egg (as a development one or not) in an automated 
> fashion, which is exactly what you'd want from a buildout.

At least it's what I want. That is, easy_install may as well put things 
in the ether as far as I'm concerned, and I'm more comfortable with a 
single file (buildout.cfg) that gives me an overview of which eggs my 
application consists of.

Very open to be persuaded otherwise, though. ;-)

>> the "source bin/activate" dance is the only thing I see being a 
>> detriment here(and with the latest workingenv, your shell prompt lets
>> you know you are in an env).
> Not everybody likes the activate dance. With buildout, you don't need 
> it. The recipes make sure that the scripts that get installed into the 
> buildout's 'bin' directory have the right PYTHONPATH set and have access 
> to the eggs you requested for the buildout.

On the one hand, this patching is a bit odd, but probably just a result 
of the fact that Zope itself isn't terribly egg/pythonpath friendly. On 
the other hand, I don't like the stateful nature of the activate dance 
to point where it feels hacky to me. I know others disagree, though.

> I see no problem with that. zc.buildout is one way of deploying Python 
> software like Zope. As long as you've got eggs, you could install them 
> manually into your workingenv just fine. buildout just does it an 
> automated fashion (and, of course, it can do more than just installing 
> eggs).

... and I've come to like its approach to stringing together recipes and 
passing options. It fits my brain. :)

> I'm not too fond of zc.buildout's directory scheme eiher. In particular, 
> I wish that it would use 'lib/python' instead of 'eggs' and 'src' 
> instead of 'develop-eggs'. I don't know enough zc.buildout details to be 
> able to say whether that can be chagned by remimplementing the egg 
> installation recipe. I would sure hope it is.

in buildout.cfg, I did:

eggs-directory = lib/python
develop-eggs-directory = lib/python

Eggs are now in ${buildout}/lib/python, and it seems to work fine (but I 
had to stop short of testing in detail). I imagine that if workingenv 
was told of the same directory, the two would co-exist.

I want to play with the zope 2 recipies to make filesystem layout a bit 
more flexible in these.

>> as stated before, I don't mind using zc.buildout, but I don't want to 
>> have to learn zc.buildout to use it meaningfully in my existing setup. 
>> If a buildout recipes could be executed by themselves(like 
>> buildout-zope2, buildout-deliverance, buildout-squid) as well as by 
>> aggregated recipes.  This would make buildout a killer tool inside my 
>> workingenv rather than a choice I had to make between two technologies.
> As said already, I think once you've got buildout, there's no need for 
> workingen, except if you think that "Zope stinks" ;)

Plone stinks!


More information about the Zope-Dev mailing list