Comment 2 for bug 164043

On Nov 20, 2007 4:21 PM, Jim Fulton <email address hidden> wrote:

> Getting back to your use case, can't you just add an empty option for
> the package to cancel previous definitions:
>
> [buildout]
> develop = checkout_of_foo
>
> [version]
> foo =
>
> If this doesn't work, I'd be happy to make it work.

Since the version list is maintained externally you'd need to do an
override with an empty version. I don't know whether that works but I
can try.

I don't like it as it's repeating yourself in one more place, plus you
need to have the underlying knowledge that the version you're trying
to develop is in the versions list at all. This versions list in our
case is external using an extends, so it's not instantly obvious.

I disagree with preferring the 'develop' eggs. I can see it's wrong
that it picks them up from the system, but that to me seems more like
a search path issue. It doesn't prefer the develop egg now if you
include a version. Do you mean that it would not even get the develop
egg if it's listed as a hard-coded version in someone's setup.py? As
you say, this adds the requirement that the setup.py will have to
include the future version for something to get picked up as a develop
egg. Besides this requiring multiple places again (buildout.cfg and
setup.py), this won't work if you are not depending on the egg you
want to develop directly, but indirectly through someone else's
setup.py. I don't know whether you can override this using the
versions list again. It also can potentially make development on
branches that exist through multiple releases harder, as your future
version number may not remain to the future.

Why not solve the search path issue and let people express develop
eggs clearly in one place instead? It seems more straightforward than
requiring multiple places, more knowledge, and different ones in
different circumstances (setup.py versus a versions list, and
potentially both at the same time). So this looks harder and less
explicit.