fix and make common python version normalization#385
fix and make common python version normalization#385neersighted merged 4 commits intopython-poetry:mainfrom
Conversation
dimbleby
force-pushed
the
consistent-python-version
branch
from
f554b71 to
3d1d83a
Compare
dimbleby
force-pushed
the
consistent-python-version
branch
from
3d1d83a to
a571fa5
Compare
neersighted
left a comment
neersighted
left a comment
There was a problem hiding this comment.
I think that being bug/implementation compatible with Pip here is, unfortunately, the correct move. That being said, I would like to put a streamlined version of your testing/research in the docstring or comments as appropriate. Looks good to merge after that.
Also handle a single digit of precision more carefully at the boundary.
|
I added a comment. I also went to the trouble of installing python 3.0.0, to see how single digit precision really works at the edge cases. Turns out that So I've added a comment saying that, and updated the code accordingly (not that there's anyone out there running 2.0.0 or 3.0.0 who will ever care about the difference) |
|
Hmm, not sure I appreciate sonarcloud telling me that it doesn't like this code, let's try a small rearrangement... |
dimbleby
force-pushed
the
consistent-python-version
branch
6 times, most recently
from
fcb9446 to
f4e3732
Compare
dimbleby
force-pushed
the
consistent-python-version
branch
from
f4e3732 to
8207439
Compare
|
Kudos, SonarCloud Quality Gate passed!
|
|
Good luck to anyone who thinks they can make this function satisfy sonarcloud, I've suppressed the warning |
Honestly I find the SonarCloud-driven version to be more readable and cleaner :) LGTM if suppressing Sonar is all we can do, despite the mild refactor. |
Also handle a single digit of precision more carefully at the boundary.
2 participants
relating to python-poetry/poetry#5717
there were two similar but diverging bits of code. They really ought to be the same; and the version that I've gone for is actually not quite the same as either of the originals.
Specifically, in the handling of python_version when specified with either one or two digits...
First, the single digit case.
python_version > 3is strictly not valid, PEP 508 says that thepython_versionshould be equivalent to'.'.join(platform.python_version_tuple()[:2]).pipand arequirements.txtteaches me that in my 3.8.10 environment,python_version > 3does allow a dependency to be installedpython_version <= "3"does not allow installation at 3.8.10>3as> 3.0.0per Fix an error when handling single digit Python markers #155 is reasonable, and have removed code that treats>3as>=4.0.0For the two digit case though, experiment shows that
python_version > "3.8"does indeed cause pip not to install a dependency in my 3.8.10 environment, that I think should be reinterpreted as>=3.9.0. So I have included that code.