[proposal] requires_python attribute

[arrdem]

While having a global Python interpreter choice works fine for small repositories, in large repositories there are potentially considerable code compatibility concerns across interpreter/virtualenv versions and migrations of language versions require supporting split states where some targets have converted and others may not have converted.

Today it's possible to set up multiple Python toolchains and multiple virtualenvs and use build configuration to choose how a given target or group are built/tested and that works fine.

A problem we've encountered is that users who wish to drop backwards compatibility have a hard time doing so in a sound way. Consider a service which has been able to adopt a new interpreter and would like to adopt new language features such as := or match. Code which has adopted a syntax extension feature like this is no longer backwards compatible to earlier interpreters which can cause problems both in linting and if there are targets configured for older interpreters which depend on targets that have adopted these features.

The idea I've been kicking around is to extend PyInfo with a requires_python attribute expressing the interpreter constraint range same as in setuptools. It should also be possible for at a minimum the py_binary rule implementation to perform a consistency check over all the PyInfo.requires_python values and ensure that the rule as defined contains only compatible sources. It would also be desirable to be able to restrict eg. rules_lint behavior so that 3.8 linting would be applied only to 3.8 compatible sources; the alternative being choking on 3.11 features.

Thoughts?

[aignas]

Is the ask not covered already with something like:

    target_compatible_with = select({
        "@rules_python//python/config_settings:is_python_3.9": [],
        "//conditions:default": ["@platforms//incompatible"],
    })

As for aspects traversing the graph, I am not sure about what would be the best option here.