[Distutils] markers, =?utf-8?Q?<=3D_?=and python 2.7.10

[Donald Stufft]

On July 1, 2015 at 12:33:29 AM, Nick Coghlan (ncoghlan at gmail.com) wrote:
> On 1 July 2015 at 11:44, Robert Collins wrote:
> > So - 426 markers specify string comparisons only. This is now broken
> > in the wild :)
> >
> > We need to figure out:
> > - what comparisons we should allow (e.g. - versions, or tuples, or ?)
> > - what the migration strategy for early adopters looks like
> > - do we change the meaning of python_version
> > - do we define a new symbol name
> > - do we break existing markers, or force some type gymnastics
> > (e.g. casting the user side of the marker to a sequence of
> > components)?
> >
> > https://bitbucket.org/pypa/setuptools/commits/e01e9a77fad5
> > https://github.com/pypa/pip/issues/2943
>  
> From a logistics perspective, I think it makes sense to pull
> environment markers out into their own PEP so we can standardise them
> independently of the full PEP 426 specification.

Agreed, especially since they are already being used in the wild, so it
makes sense to get them standardized sooner rather than later.

>  
> From a "how to fix it?" perspective, I think it makes sense to say
> that any marker ending in "_version" is compared using PEP 440 version
> ordering semantics rather than lexical ordering
>  
> My rationale for that is:
>  
> 1. In the simple X.Y.Z cases, lexical string comparisons and PEP 440
> give the same answer
> 2. In the more complex cases (like 2.7.10), PEP 440 gives the right
> answer, while lexical string comparison fails
> 3. Anything handling environment markers already needs to be able to
> handle PEP 440 semantics anyway
>  

Also agreed. Perhaps the ``_version`` markers should just support the
full range of specifiers in PEP 440. 

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