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
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
