On Feb 9, 2008, at 2:32 PM, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Martin Aspeli wrote:
Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Chris Withers wrote:
Hi All,
What are the alternatives to zc.buildout?
I'm wondering before I plough into zc.buildout because I'm guessing other big projects have run into the problem of pinning certain versions of eggs, building "instance homes" for projects, using a mixture of "public" eggs and those that are private and for a specific project, etc and otherwise working round limitations in setuptools... The major competitor for mindshare is probably Ian Bicking's 'virtualenv': it makes using 'easy_install' *really* easy, because you are working in a sandbox.
The standard installs for repoze.zope2, repoze.grok, repoze.plone, etc. all assume a virtualenv, and add scripts which turn the vanilla virtualenv into an "instance."
The problem I have with virtualenv - or rather, with raw setuptools based solutions - is that it's difficult to uninstall eggs. With buildout, once you remove the requirement/egg line and re-run buildout, the egg is no longer installed.
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.
Which it is. Part of using buildout is understanding that anything built by buildout is controlled by it. I often make temporary hacks to created files, knowing that the changes will be thrown away on the next build. If you want to make a permanent change, you need to update the buildout configuration. There *can* be exceptions to this. We have some recipes that manage checkouts. These don't remove checkouts to avoid losing user data. Similarly, the zc.recipes.filestorage recipe doesn't remove data directories it creates on uninstall.
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 like buildout for development be because I don't have to "inhabit" the created artifacts. I (can) have a single high-level configuration that lets me control a variety of subsystems in one place. I'm sure this is a matter of taste. Jim -- Jim Fulton Zope Corporation