when versions and develop section both refer to package, prefer develop

On Nov 20, 2007, at 6:34 AM, Martijn Faassen wrote:

> Public bug reported:
>
> When you fix versions using 'versions' in the [buildout] section,
> and you also place the same package in the develop section,
> the version indicated in the versions section is preferred. This
> means that you need to *remove* the version from the
> versions list first in order to change a package into a develop
> package, otherwise the released version will continue to be picked
> up. This makes
> life harder than it should be if you work with long published lists
> of versions. In order to develop packages, you'd need to copy this
> long list and remove those packages that you'd want to change.
>
> I think the behavior should be to let 'develop' always override
> what's in the versions list. If you're going to put packages in the
> 'develop' list,
> you do this explicitly anyway, so there's little risk of mistakes.
> You want to develop those packages, not use already released versions.

I don't agree. In fact, I'd like to remove the current preference for
develop eggs, given that:

- develop eggs are also used fro many system package installs :(
- We've decided that setup.py files should have future versions.

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.

Jim

--
Jim Fulton
Zope Corporation

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.

On Nov 20, 2007, at 6:34 AM, Martijn Faassen wrote:

> Public bug reported:
>
> When you fix versions using 'versions' in the [buildout] section,
> and you also place the same package in the develop section,
> the version indicated in the versions section is preferred. This
> means that you need to *remove* the version from the
> versions list first in order to change a package into a develop
> package, otherwise the released version will continue to be picked
> up. This makes
> life harder than it should be if you work with long published lists
> of versions. In order to develop packages, you'd need to copy this
> long list and remove those packages that you'd want to change.

No.

Simply override the version for the package you're interested in by
adding:

   [versions]
   foo =

assuming that your versions section is versions and the package you
want to not have a version for is foo.

Jim

--
Jim Fulton
Zope Corporation

It's true you can override things in [versions]. It means that if your code now depends on an unreleased version (that you have checked out), you need to:

* add it to the 'develop' list in [buildout]

* remember that you should override [versions] for it.

Recursively, if you rely on a checkout that relies itself on a checkout, you need to remember not only to list both in develop of your own package, but also remember to list them both under [versions], overriding the default behavior.

I'd prefer if it just ignored the version in [versions] for any development package. Is there a use case for listing a package in develop while you *don't* want the buildout to use it? Isn't that surprising behavior?

A thread about this topic on the list :
http://mail.zope.org/pipermail/zope-dev/2008-February/thread.html#30991

I was bitten by this one a few times, it would be much more intuitive to always prefer develop version.