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  -  Zope-Dev@zope.org
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 )

Reply via email to