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