Inference of target versions from requires-python config is incorrect.
#3581
Labels
T: bug
Something isn't working
Comments
|
Currently, we treat empty requires-python metadata as if it was not present. But technically, it’s a version specifier with no clauses, so it contains all Python versions. On one hand, if we want to respect the configuration and be consistent, we should treat empty requires-python metadata as “all Python versions”. On the other hand, empty requires-python metadata is very non-explicit, so falling back to per-file auto-detection doesn’t seem too wrong, either. What do you think? |
|
You're right, |
manueljacob
added a commit
to manueljacob/black
that referenced
this issue
Feb 27, 2023
Fixes psf#3581. The old algorithm checked, for each target version 3.X, whether 3.X (which is roughly the same as 3.X.0) is contained in a version specifier that was modified from the requires-python project metadata to be less strict regarding patch versions. One problem of it was that, for a requires-python value of ">3.X" (which means the same as ">3.X.0"), it concluded that target version 3.X is not supported although Python versions >= 3.X.1 are included in the version specifier. I found the old approach hard to reason about and hard to fix. To correctly check whether a target version 3.X is supported, the algorithm must check if 3.X.* overlaps the version specifier in the requires-python project metadata. Checking only specific versions (like 3.X.0) is not sufficient in general. The `packaging` library, which implements the logic for (PEP440-compatible) versions and version specifiers, doesn’t implement checking for overlap of two version specifiers, however. The new algorithm works by converting the version specifiers to interval sets, which are then checked for overlap.
manueljacob
added a commit
to manueljacob/black
that referenced
this issue
Feb 27, 2023
Fixes psf#3581. The old algorithm checked, for each target version 3.X, whether 3.X (which is roughly the same as 3.X.0) is contained in a version specifier that was modified from the requires-python project metadata to be less strict regarding patch versions. One problem of it was that, for a requires-python value of ">3.X" (which means the same as ">3.X.0"), it concluded that target version 3.X is not supported although Python versions >= 3.X.1 are included in the version specifier. I found the old approach hard to reason about and hard to fix. To correctly check whether a target version 3.X is supported, the algorithm must check whether 3.X.* overlaps the version specifier in the requires-python project metadata. Checking only specific versions (like 3.X.0) is not sufficient in general. The `packaging` library, which implements the logic for (PEP440-compatible) versions and version specifiers, doesn’t implement checking for overlap of two version specifiers, however. The new algorithm works by converting the version specifiers to interval sets, which are then checked for overlap.
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
#3219 introduced inference of the target versions for black from the
requires-pythonproject metadata inpyproject.toml. However, it was not implemented correctly.The rules for the comparison operators in
requires-pythonis documented in PEP 440.For example,
>3.7,<3.10currently results in the inference of["py38", "py39"]. However,3.7.1is in>3.7,<3.10, so"py37"should be included as well.>3.7.0,<3.10results in the inference of["py37", "py38", "py39"], which is correct. However,>3.7.0,<3.10is equivalent to>3.7,<3.10, so they should give the same results.I re-implemented the inference code. I will open a pull request as soon as I clarified and commented the code.
The text was updated successfully, but these errors were encountered: