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
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
http://worldcookery.com -- Professional Zope documentation and training
Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -