[Distutils] PEP440: >1.7 vs >=1.7

[Donald Stufft]

> On Dec 28, 2014, at 9:57 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> 
> On 28 Dec 2014 17:12, "Donald Stufft" <donald at stufft.io <mailto:donald at stufft.io>> wrote:
> >
> >
> >> On Dec 27, 2014, at 9:26 PM, Donald Stufft <donald at stufft.io <mailto:donald at stufft.io>> wrote:
> >>
> >>
> >>> On Dec 27, 2014, at 9:10 PM, Marcus Smith <qwcode at gmail.com <mailto:qwcode at gmail.com>> wrote:
> >>>
> >>>> In gives me a minor bit of pause. However any alternative that I can come up
> >>>> with bothers me more, especially since I don't believe many people actually
> >>>> even *use* a bare > and any alternative I can come up with has worse behavior
> >>>> for operators which get much more use.
> >>>
> >>>
> >>> what about making >=,<= also use the series concept? where does that go wrong?
> >>>
> >>
> >> To be clear, you’re talking about doing something like:
> >>
> >> >1.7 is >1.7 AND !=1.7.* which would correlate to >1.7 OR ==1.7.*?
> >>
> >> Honestly, the thing that I dislike about that is it takes a behavior which is
> >> less intuitive (I do agree that the behavior of > is less intuitive) and
> >> applies to globally. I don't think people would expect >=1.7 to match 1.7.dev0
> >> and given that I don't think people would expect >=1.7.0 to _not_match
> >> 1.7.dev0.
> >>
> >> I totally agree that the behavior of > isn't the greatest, I don't think the
> >> solution to that problem is to globally apply that particular wart. The only
> >> *reasonable* solutions I can think of are:
> >>
> >> 1. Make < and > both act as simple comparison operators, and have >1.7 and
> >>    >1.7.0 both allow 1.7.1. This would include also allowing 1.7.dev0 to be
> >>    <1.7 and <1.7.0.
> >>
> >> 2. Make < and > both act as "exclusive comparison operators", and which is
> >>    the current behavior.
> >>
> >> 3. Make < and > both act as simple comparison operators, but include a special
> >>    case that < does not ever match pre-releases of the version mentioned in
> >>    the specifier. So <3 would not match a pre-released like 3.dev0, and <3.1
> >>    would not match a pre-release like 3.1.dev0 but would match a pre-release
> >>    like 3.0.dev0.
> >>
> >> It may be that the correct solution is to just treat pre-releases as special
> >> and just switch to 3.
> >>
> >
> > After thinking about this some more, I made a PR that adjusts the packaging
> > library so that is has semantics which might be better overall than what is
> > currently in PEP 440. This PR is at https://github.com/pypa/packaging/pull/25 <https://github.com/pypa/packaging/pull/25>
> > if someone wants to play with it at all, but the highlights are:
> >
> > * 1.7.1 matches >1.7 (previously it did not)
> 
> This sounds like a straight up bug fix in the packaging module to me - the PEP 440 zero padding should apply to *all* checks, not just to equality checks, as you can't sensibly compare release segments with different numbers of elements.
> 
> Hence this sentence in the description of the release segment under the "Final releases" heading: "When comparing release segments with different numbers of components, the shorter segment is padded out with additional zeros as necessary."
> 
> The zero padding does get called out again explicitly in the section on version matching, but that's in the context of explaining why "== 1.7" will match "1.7.0" and vice-versa, even though version matching is otherwise strict.
> 
> > * 1.7.post1 does not match >1.7 (previously it did not)
> > * 1.7.post1 matches >1.7.post0 (previously it did)
> > * 3.dev0 does not match <3.0 (previously it did)
> 
> This is another bug fix - avoiding that match is one of the key reasons for the wildcard exclusion in the definition of the exclusive comparison operators.
> 
> Given the next bullet point, it sounds like this may have been another symptom of incorrectly limiting the release segment zero padding to version matching operations.
> 
> > * 3.0.dev0 does not match <3.0 (previously it did not)
> > * 3.0.dev0 matches <3.0rc1 (previously it did)
> >
> > Instead of having >V and <V impliy !=V.*, this means that:
> >
> > 1. A <V does not match a pre-release of V unless V is itself a pre-release.
> > 2. A >V does not match a post-release of V unless V is itself a post-release.
> > 3. A >V does not match a V+local.version.
> 
> Please don't make the change more complicated than it needs to be - there's just a bug in the packaging implementation of the PEP semantics. Zero padding of the release segment should be applied to all operations, and that currently isn't happening.
> 
> Regards,
> Nick.
> 

The > and < operators are currently implemented exactly how they are defined in
the PEP. If we want to change that, that's fine, but the packaging library is
correct to the PEP currently.

The PEP says:

    Exclusive ordered comparisons are similar to inclusive ordered comparisons,
    except that the comparison operators are < and > and the clause MUST be
    effectively interpreted as implying the prefix based version exclusion
    clause != V.* .

    The exclusive ordered comparison > V MUST NOT match a post-release or
    maintenance release of the given version. Maintenance releases can be
    permitted by using the clause > V.0 , while both post releases and
    maintenance releases can be permitted by using the inclusive ordered comparison >= V.post1 .

    The exclusive ordered comparison < V MUST NOT match a pre-release of the
    given version, even if acceptance of pre-releases is enabled as described
    in the section below.

    Local version identifiers are NOT permitted in this version specifier. 


The packaging lib currently does exactly that, given a specifier like >1.7 it
transforms it to >1.7 and !=1.7.*. The PEP even calls out the fact that a
maintenance release of the same series should not match and if you want it to
match then you should add a zero yourself.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20141228/531932b9/attachment.html>