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?
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?