Tres Seaver wrote:
My major beef with zc.buildout is perhaps actually a problem with the recipes nearly everybody uses: they blow away hand-edited stuff without warning. In particular, changes to things like the zope.conf file get zapped, because buildout (or the recipe) thinks that the file is its own personal property.
This is an implementation detail of the plone.recipe.zope2instance recipe, which indeed does make that assumption. You do have the option of specifying an alternative zope.conf file with this particular recipe that's not touched, but that's obviously a recipe-specific problem and solution. In some cases, stomping *is* the right solution, enabling you to return to a "known good" state every time. It's more of a cultural and documentation thing than anything else.
That said, I like virtualenv and use it a lot. I just think it solves a slightly different use case from the "repeatable configuration management system" one that buildout tries to solve.
My sense is that zc.buildout's focus on "production deployment" usecass is the source of a lot of my frustration with it as a developer: I expect to "inhabit" the environment it creates, which is completely irrelvant in a production rollout.
I find it very useful in a development setting, and find that it makes the tasks of moving from development to staging to production more manageable. That said, it's not as easy as just doing "python setup.py install" in a virtualenv to trial something out. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book