[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:
[buildout]
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!
Martin
More information about the Zope-Dev
mailing list