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

[Philipp von Weitershausen]

Rob Miller wrote:
> honestly, it seems to me that buildout tries to do too much. 

That's ok. I often don't need the big hammer that buildout is. That's 
when I tend to use workingenv (even if it's' just for trying out whether 
something's easy_install'able)

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

Buildout is actually quite simple, it took me a while to grok it, too. I 
started writing a tutorial for it but got interupted by other stuff. I 
sure hope to finish it.

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

I think buildout can serve well for sandboxes if you work in a team, 
because everybody uses the same recipe for sandboxes.

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

There's nothing Zope specific about buildout. It just happens to be 
developed by Zope people. The egg and cmmi recipes allow it to be used 
for the majority of other Python software out there, though (and if 
that's not enough, you can alway simplement a custom recipe).

Note that I bounced off of it too, until Martijn and Christian explained 
it to me and it was forced on me via grok. It's purely a documentation 
issue, I think.

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

Sure. My point has always been that everybody should choose the tools 
they understand best. I think there's a place for both workingenv and 
buildout out there. I don't think that's short-sighted.

My only assertion was that using workingenv and buildout together seems 
like overcomplicating things, as they're both trying to solve a lot of 
similar issues.

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