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


_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Reply via email to