On 27 Sep 2007, at 00:14 , Jim Fulton wrote:
Let's say X depends on Y and I'm developing them simultaneously as development eggs in one sandbox (e.g. buildout). I add a feature to Y that I'd like to use in X. That means I'll have to change X's version dependency regarding Y so that it now depends on Y>a.b where a.b is the latest release that didn't have the feature I added.

Will Y with the setup.py stating version='unreleased' satisfy the Y>a.b requirement that X (rightfully) has? If not, then I think we have a problem. If yes, then I find that very confusing.

Leaving aside for the moment the fact that "develop" eggs are used for system egg installs :(,

I think if a buildout uses a develop egg, there should be a very strong presumption that it it should be used. OTOH, if you have a part that depends on a previous major version, then you don't really want to use a develop egg for the later release. This is a bit of an edge case though.

It is as long as you ignore the fact that all major Linux distros install develop eggs into site-packages.

I still see the development egg case the best argument for putting the next anticipated version number into setup.py. I think the compromise of version number + 'dev' marker would work best.

I agree that the develop egg case is problematic. I'd like to think about that.

If you ever actually make dev releases, then guessing wrong about the next version could cause real problems.

Oh, I'm not actually thinking about dev releases. I too think they're very problematic. I just suggested using the 'dev' marker as a way to tell branches or the trunk apart from tags. On the branches and trunk, setup.py's version is the next anticipated release + 'dev', while on tags it's just release version. That way people won't accidentally make releases from branches or the trunk (because they'd get an egg with a 'dev' in the version). They'll have to use a tag.

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to