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

[Philipp von Weitershausen]

whit wrote:
> Martin Aspeli wrote:
>> 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...
> 
> is there some advantage to the way that buildout handles eggs over 
> workingenv. as I understand it, workingenv *only* handles python setup 
> and does that well and transparently.

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.

> 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.

>> 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.
> 
> what about if I'm already using workingenv... and want to use zope or 
> plone in my workingenv?

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).

> currently, I don't see an easy way to use buildouts inside a workingenv, 
> whereas the rest of python world works great.  I will have alot of 
> trouble explaining to my developer who already think zope smells that 
> they have to change the way they work to use zc.buildout recipes.
> 
> for example, I can't use the deliverance or lxml buildout with an 
> existing topp.deploy workingenv because of buildout's arbitrary egg 
> handling scheme.  If zc.buildout didn't try to do so much, the python 
> would be installed transparently like everything else I easy_install.

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.

> 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" ;)

-- 
http://worldcookery.com -- Professional Zope documentation and training
Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5