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

[Martin Aspeli]

Rob Miller wrote:

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

Potentially. But I find it kind of reassuring to have a well-defined 
list of which eggs are part of my "special" environment i.e. the one 
tied to my instance.

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

Again, I think the two are orthogonal.

And honestly, I found zc.buildout pretty easy to understand. I resisted 
it for a while, it seems liked it *should* be complex, and I won't 
pretend to understand how it manages eggs in any detail, but I don't 
think it matters.

Look at http://dev.plone.org/plone/browser/ploneout/trunk/buildout.cfg - 
I find that pretty self-explanatory. I tried to document how it works at 
a high level and how you may use it here 
http://dev.plone.org/plone/browser/ploneout/trunk/README.txt.

And writing a new recipe is as simple as this:

http://dev.plone.org/plone/browser/ploneout/trunk/src/z2c.recipe.zope2checkout/src/z2c/recipe/zope2checkout/__init__.py

All that is plain python code, the only thing you need to understand 
about buildout is that it has a dict-like object called 'options' which 
reflects the options in the current part's section in buildout.cfg, and 
a higher level dict-like object called 'buildout' which has the options 
for all the parts (so buildout['foo'] are the options for part [foo] in 
buidout.cfg). Each part is associated with a recipie. Recipies are ordered.

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

You can do that quite easily with buildout as well. I would like to make 
a more generic recipe for retrieving tarballs for e.g. zope 
installation, and I think it'd be as hard as figuring out which python 
function to use to download something.

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

Again, if you want a recipe to do that, it's trivial to write (10 lines 
of code?). Instead of an external script, though, I would probably find 
it easier to write that as a buildout recipe in python.

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

I'm just struggling to see why it's so hard to figure out how buildout 
works. Perhaps it just fits my brain. But honestly, once Hanno showed me 
his initial steps with ploneout and I'd taken ten minutes with pdb 
inside the __init__() and install() functions (the only two...) in his 
recipe the pieces fitted together in my head almost instantly.

I don't greatly care how the standard zc.recipe.egg mechanism installs 
eggs because it works and because I can see clearly where they come 
from, how I create new ones and I'm satisfied that they are available ot 
my python interpreter. If I did care, I'm sure I wouldn't find it that 
hard to trace, though.

Martin