RFE: infer target-version from project metadata

[scop]

target-version could in many cases be inferred from project metadata:

• https://packaging.python.org/en/latest/specifications/declaring-project-metadata/#requires-python
• https://packaging.python.org/en/latest/specifications/core-metadata/#core-metadata-requires-python

Would be great to see ruff do that to eliminate one maintenance chore.

Black is moving toward doing that, too. The implementation over there is obviously somewhat different, because they still take a list of target versions whereas ruff takes the minimum one (which I think is the better, yet less flexible approach). Perhaps some of that work can be reused in ruff: psf/black#3219

[charliermarsh]

Perhaps we can use https://github.com/konstin/pep440-rs from @konstin to power the version parsing?

[ilkersigirci]

FYI: black#3219 was merged and shipped with black 23.1.0

[manueljacob]

Black’s target version inference is currently broken: psf/black#3581. I’m currently working on a fix and would be happy to port the solution to ruff. However, before that, #2519 should be decided.

[charliermarsh]

Nice! I'm happy to support target ranges, it's just not totally clear to me what rules they would affect and how.

[JonathanPlasse]

Black have different behaviors depending on the versions for example. Maybe ruff formatter should do the same.

[konstin]

one thing to consider is that the behavior in psf/black#3581 (>3.7 still implying 3.7 code styles) is most likely unintended and imho >3.7 (as opposed to >3.7.1 or >=3.7) should raise a warning (or you could emit linter errors for ruff's own configuration :D) EDIT: See also Y006 in flake8-pyi ("Use only < and >= for version comparisons. Comparisons involving > and <= may produce unintuitive results when tools do use the full sys.version_info tuple.")

[JonathanPlasse]

Should we close this issue?

[konstin]

yep

[charliermarsh]

I created #3487 to track inferring this info at runtime.