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.

-- -- Professional Zope documentation and training
Next Zope 3 training at Camp5:
Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to