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