Python version confusion#457
Conversation
6d6d2bd to
936dae2
Compare
6c07428 to
71bbb18
Compare
Is there some reference that confirms this? (For markers PEP 508 says that |
|
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 |
|
This also implies that poetry is doing it wrong when the the python requirement is eg So I've erred on the side of caution and left that alone. |
|
Kudos, SonarCloud Quality Gate passed! |








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.10is interpreted as<3.11- whereas it should be equivalent to<=3.10.0NB there is no problem with the normalization of python markers: a marker like
python_version <= "3.10"is equivalent topython_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_versionmarker from a constraint be more careful of this edge condition, we now explicitly zero-pad and usepython_full_versionwhen we hit it.(IMO this is not important enough to delay the upcoming 1.2.0 release).