markers, <= and python 2.7.10
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 -Rob -- Robert Collins <rbtcollins@hp.com> Distinguished Technologist HP Converged Cloud
On 1 July 2015 at 11:44, Robert Collins <robertc@robertcollins.net> 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.
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 Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On July 1, 2015 at 12:33:29 AM, Nick Coghlan (ncoghlan@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
On 2 July 2015 at 01:37, Donald Stufft <donald@stufft.io> wrote:
On July 1, 2015 at 12:33:29 AM, Nick Coghlan (ncoghlan@gmail.com) wrote:
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.
That's what I was thinking. The one slight difference is that I don't believe we'd want any special case handling of pre-releases in environment markers - if I have a Python alpha installed, I'd want it treated as equivalent to the corresponding final release, since constraint checking isn't the same as choosing the "best" version for download/installation. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On July 2, 2015 at 10:34:35 AM, Nick Coghlan (ncoghlan@gmail.com) wrote:
On 2 July 2015 at 01:37, Donald Stufft wrote:
On July 1, 2015 at 12:33:29 AM, Nick Coghlan (ncoghlan@gmail.com) wrote:
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.
That's what I was thinking. The one slight difference is that I don't believe we'd want any special case handling of pre-releases in environment markers - if I have a Python alpha installed, I'd want it treated as equivalent to the corresponding final release, since constraint checking isn't the same as choosing the "best" version for download/installation.
Well, even in the case for dependencies we say that a pre-release should be accepted if it’s installed which would be in that vein IMO. I agree that it’d be useful to call that out explicitly though. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On 3 July 2015 at 02:03, Donald Stufft <donald@stufft.io> wrote:
On July 2, 2015 at 10:34:35 AM, Nick Coghlan (ncoghlan@gmail.com) wrote:
That's what I was thinking. The one slight difference is that I don't believe we'd want any special case handling of pre-releases in environment markers - if I have a Python alpha installed, I'd want it treated as equivalent to the corresponding final release, since constraint checking isn't the same as choosing the "best" version for download/installation.
Well, even in the case for dependencies we say that a pre-release should be accepted if it’s installed which would be in that vein IMO. I agree that it’d be useful to call that out explicitly though.
+1 For the benefit of the list, note that James Polley has started a draft of this extracted PEP: https://github.com/pypa/interoperability-peps/pull/29 Aside from the version handling, I'm not aware of any other major gripes with the current environment markers, so now's the time to let me know if there are other actual problems that need to be fixed :) (I'm not worried about missing features at this point - it's hard for those to qualify as urgent given how long we've already gone without them, but handling 2.7.10 correctly is pretty important) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (3)
-
Donald Stufft -
Nick Coghlan -
Robert Collins