I’m a bit stuck on how to implement https://github.com/pantsbuild/pants/issues/9273 to deprecate

[python-setup].interpreter_constraints

being a list option. If a user sets

interpreter_constraints = '>=3.6'

, that means to add the constraints to the default, rather than to replace. Almost always, that’s an error to add. I don’t see how a user can avoid using list syntax while still overridding? The simplest I can think of is to deprecate

interpreter_constraints

and rename to

interpreter_compatibility

or

compatibility

, for closer alignment with the

compatibility

field. The complex, slow approach is: 1. Deprecate not setting constraints, so that we can set them to empty by default. 2. Deprecate the list syntax. You will still be appending, but you’re appending to the default of an empty list. 3. Change the type, add back our default. The downside is that we can’t finish this till 2.3.0, and we have no default in 2.2.0 for new users.

If you are changing the name of the config can’t you have them overlap where the existence of the newer one makes the older one ignored?

Indeed. If we change the name of the option, then this is easy to do

Does TOML have a syntax for overriding lists instead of appending?

For Pants options, that’s what the

interpreter_constraints = [">=3.7"]

is doing: overriding. We don’t have another mechanism to override, and I don’t think we want to invent one

Is “requires” a pip or pypi field? Would that work?

We could possibly do it, but yeah overlaps with our options like

[python-setup].requirements_constraints

, which may be confusing

Isn’t that really

pip_contraints

?

The simplest I can think of is to deprecate 

interpreter_constraints

 and rename to 

interpreter_compatibility

 or 

compatibility

, for closer alignment with the 

compatibility

 field.

this makes sense to me, but mostly because it aligns with the field name on targets. making them align around some other new name would be good too though.