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
_______________________________________________
Zope-Dev maillist - [email protected]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
