Martin Aspeli wrote:
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.
to find this i simply look in /path/to/workingenv/lib/python2.4.
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.
orthogonal, but with overlap.
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.
i have no doubt that zc.buildout will do everything that buildit will do, and
probably much more. but i like simple. and for me, having something light
like workingenv to manage my sandbox, and a library like buildit for putting
files into those sandboxes feels simple.
- 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.
the script could of course be python as well.
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.
your efforts to figure something out and then document will have a major
impact on people understanding this, as per usual. but still, something about
it just feels heavy. the idea of having two separate tools, each of which
does one thing well, working together to solve a problem suits my
sensibilities more than having one more monolithic tool.
luckily, we don't really have to convince each other of anything, here. it's
entirely possible to have zc.buildout recipes for installing Zope and Plone as
well as buildit / workingenv recipes for the same purpose.
-r
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )