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

[Rob Miller]

Philipp von Weitershausen wrote:
> 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.

honestly, it seems to me that buildout tries to do too much.  it's trying to 
handle both repeatable deployment recipes AND providing a sandbox within which 
to run things.  there may not be a point to having an extra layer on top of 
buildout, but buildout sure does seem to me a bit heavy if all i want is a 
sandbox.  so now i have to learn the workingenv way if i just need a sandbox, 
but i have to learn the buildout way if i also want repeatable deployments?

  >>> Workingenv made it more complex than it needed to be (or buildout
>> 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" ;)

this is shortsighted, IMO.  i know zope quite well, but i bounced off of 
buildout b/c it required too much knowledge to even get started.  i think it's 
much more likely that people from the greater python community will pick up 
and start using workingenv than they will zc.buildout.

personally, i like chris mcdonough's approach with his buildit package.  it 
does two things:

- it retrieves files from anywhere on the 'net (cvs, svn, tarball, whatever) 
and puts them where you want them on your target machine(s)

- it launches external scripts that then perform whatever final configuration 
you may want to perform.

buildit is also recipe driven, and it's smart enough to pick up where it left 
off on a previous run, a'la make.  i'd guess that you could use buildit and 
workingenv to accomplish pretty much everything you can do w/ zc.buildout, and 
you wouldn't have to bend your brain so much to do so.

-r