Python version confusion #457

dimbleby · 2022-08-29T17:37:01Z

Undoing #407 and taking a different approach. (Can confirm that this still fixes python-poetry/poetry#5591).

When setting python versions we also construct a marker to carry the same information. Prior to #407, the python constraint and python marker were not consistent, which that MR fixed by re-parsing the constructed marker into a fresh constraint.

This was nonsense: the constraint was right all along, it was the constructed marker that was wrong.

The result is that as of today a python requirement like <=3.10 is interpreted as <3.11 - whereas it should be equivalent to <=3.10.0

NB there is no problem with the normalization of python markers: a marker like python_version <= "3.10" is equivalent to python_version < "3.11". But that was never the correct marker for the python requirement.

So in this MR I revert #407, and make the construction of a python_version marker from a constraint be more careful of this edge condition, we now explicitly zero-pad and use python_full_version when we hit it.

(IMO this is not important enough to delay the upcoming 1.2.0 release).

radoering · 2022-08-29T17:50:05Z

The result is that as of today a python requirement like <=3.10 is interpreted as <3.11 - whereas it should be equivalent to <=3.10.0

Is there some reference that confirms this? (For markers PEP 508 says that <=3.10 is equal to <3.11.)

dimbleby · 2022-08-29T17:51:43Z

discussion in pypa/pip#11420 - where I tried to tell the pip folk that they were doing it wrong but they persuaded me of the opposite - points at PEP 440

dimbleby · 2022-08-29T17:57:47Z

This also implies that poetry is doing it wrong when the the python requirement is eg ==3.6, this too should be treated as ==3.6.0. However that would break the case where the python requirement was 3.6 - and it is hard for poetry to tell these apart, anyway it would have to be done before parsing the text into a constraint.

So I've erred on the side of caution and left that alone.