[Zope-dev] Re: buildout 'versions' and 'develop' conflict

Martijn Faassen faassen at startifact.com
Tue Feb 26 09:15:31 EST 2008


Christian Theune wrote:
> Martijn Faassen schrieb:
[snip]
>> It's a clear DRY violation, the name of the package (and even the 
>> version number) repeats here.
> 
> It's not clear to me that it's a DRY violation (see my argument that 
> those functions are actually orthogonal).

The rule for the most common use case is now:

If you want to develop a package, add it to 'develop' *and* create a 
versions section if it doesn't exist, let the 'versions' line in 
[buildout] point to it, and add the "package_name = " to it.

I see a repetition in the package name here. You list it in two places. 
I think that's a DRY violation given that wanting a package listed in 
develop to be picked up is the most common use case.

 > When applying DRY we still need to beware that we don't lock out
 > combinations that are currently possible/helpful.

Why would I want to list a package under 'develop' in a buildout and not 
have it be picked up? A combination only needs to be possible if it is 
helpful, so could you please give me an example a use case where this 
doesn't happen that is helpful? I'm really struggling to come up with a 
use case where you want to add a development package to the search path 
and then have it never being picked up.

 > I experimented with recipes that change other recipes' configuration
 > at run-time, but had a bad experience because of the part-ordering
 > that prevents this, otherwise I'd say you could use a recipe for
 > simpler declaration of develop eggs. That would make you type more in
 > each buildout, though.

I just want to add the behavior to buildout. Then I can tell people, if 
you want to develop a package, use "really_develop".

I started trying to add a test to buildout that demonstrates the current 
behavior (not really_develop). Strangely enough, it fails! I asked on 
the distutils list what I'm doing wrong. The branch is 
'faassen-develop'. (there are some unrelated test failures too, but they 
exist on the trunk too for some reason)

Regards,

Martijn



More information about the Zope-Dev mailing list