<@U06A03HV1> "named interpreter constraints" a la ...
# development
h
@witty-crayon-22786 "named interpreter constraints" a la your "named resolves" idea is a great way forward to address my concerns about enabling
interpreter_constraints
by default. Some "blessed" interpreter constraints will be defined via
[python-setup]
, then targets set things like
interpreter_constraints="py2_and_py3"
👍 2
It addresses my two concerns! 1. It's no longer as easy to unintentionally use an advanced feature. You can only use pre-blessed ICs, and if you add a new one to pants.toml hopefully the right people will see it. 2. We can quickly determine if the repo is using >1 IC by looking at the option, rather than scanning the whole repo
Cc @early-jelly-55072 @helpful-lunch-92084, any thoughts?
e
Nate solved this using macros but the only setting was ICs. How would this improve on just using macros?
h
Macros are valid too, but this is more first-class. It does the right thing by default, rather than requiring that you realize you should use a macro and then requiring that all your developers are disciplined in using that macro (also unlocks some performance improvements in codebases using only a single interpreter constraint for whole project)
👍🏽 1