hundreds-father-404
10/28/2020, 2:59 PM[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.jolly-midnight-72759
10/28/2020, 5:31 PMhundreds-father-404
10/28/2020, 5:32 PMinterpreter_constraints
> compatibility
jolly-midnight-72759
10/28/2020, 5:34 PMhundreds-father-404
10/28/2020, 5:36 PMinterpreter_constraints = [">=3.7"]
is doing: overriding. We don’t have another mechanism to override, and I don’t think we want to invent oneThe word “interpreter” seems important in the global context.We could do
interpreter_compatibility
, possiblyjolly-midnight-72759
10/28/2020, 5:37 PMhundreds-father-404
10/28/2020, 5:39 PM[python-setup].requirements_constraints
, which may be confusingjolly-midnight-72759
10/28/2020, 5:41 PMpip_contraints
?witty-crayon-22786
10/28/2020, 5:42 PMThe simplest I can think of is to deprecatethis 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.and rename tointerpreter_constraints
orinterpreter_compatibility
, for closer alignment with thecompatibility
field.compatibility