[Distutils] Local version identifiers from PEP 440 in practice
ethan at stoneleaf.us
Wed Dec 17 03:10:43 CET 2014
On 12/16/2014 05:49 PM, Donald Stufft wrote:
> So the *primary* use case that motivated local versions is things like when Debian
> patches a copy of a project they can indicate that they’ve done so by changing the
> version to 1.0+dfsg1 or so instead of 1.0. A related use case is the one you’re
> talking about. However the primary use case is what influenced the fact that ==1.1
> matches ==1.0+foobar.
> Important to note, is that ==1.0+foobar will only install that patched version,
> not any 1.0 version. You can also approximate the kind of pinning you want with
> the === (which is really the arbitrary equality indicator, which is generally used
> for people who want to install a version like “dog” which we can’t parse). It’s
> possible that we could add some sort of a “None” indicator for local versions that
> says “1.0 and exactly 1.0” though I’m not sure how off the top of my head (Maybe
Let me see if I understand correctly:
I release my dbf package as 1.3.
Somebody at Debian fixes a bug, and rather than wait for me to release the next version just slap a local tag on it --
so now there is:
- 1.3 (mine)
At this point, a non-debian user asking for 1.3 will get mine, whereas a debian user would get the 1.3+debian1 version.
Correct? Plus, a debian user asking for 1.4 would also get 1.3+debian1?
Now, I fix that bug plus a few more, and make a 1.4 release. A non-debian user would get my 1.4 release. Which version
will a debian user get?
- 1.3+debian1 ?
- 1.4 ?
If my 1.4 does not sort higher than a 1.3+blahblah anything, that's not good.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: OpenPGP digital signature
More information about the Distutils-SIG