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

[Martin Aspeli]

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.

I can't really answer, but it seems to be quite similar but more tightly 
controlled.

You may find the doctests in zc.buildout 
(http://svn.zope.org/zc.buildout/trunk/) and zc.recipe.egg (same svn 
location) interesting reading, e.g. easy_install.txt.

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

As I've been talking to Whit about off-list, I find this "jail" somewhat 
uncomfortable. He disagrees. :)

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

The way I'd sell it is that buildout lets you define a particular 
"build" that is to be used for repeatable deployments.

Again, I'm not sure I quite see why the two can't be orthogonal in real 
use, e.g. the global python envionment is available to something inside 
a buildout even if it's come from workingenv (i.e. it wouldn't care).

> 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 don't see why you couldn't? If a zope instance was built with 
zc.buildout why wouldn't it also find something "global" (but actually 
local provided by workingenv)?

And put differently, how does workingenv help you solve the "what is the 
set of packages I need to deploy my application properly and how do I 
set it up in a repeatable way" (which includes not only eggs but also 
data and configuration).

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

I would've thought that'd work. Not sure about aggregation, but recipies 
are very simple and deployed as eggs (you refer to it by name, buildout 
finds it in pypi or your path).

Martin