I'm adjusting

interpreter_constraints

. The key piece I'm questioning is in this BUILD file: https://github.com/StackStorm/st2/pull/5850/files#diff-a1de578ad6ec792e46e84af2ab04188980ed060c25f673c018cf0cf4bd142d93 I had interpreter constraints in

pants.toml

for the

pants-plugins

resolve without applying them here. I assumed that the

[python.resolves_to_interpreter_constraints].pants-plugins

would automatically be applied to anything that used that resolve. But, the default comes from

[python].interpreter_constraints

instead, which is not compatible with that resolve. Was my assumption off base? Why do I need to duplicate the constraints in both places? Could we change how default

interpreter_constraints

get calculated so it uses

[python.resolves_to_interpreter_constraints].<resolve>

first before falling back to

[python].interpreter_constraints

? Is there a feature here that I'm misunderstanding?

cc @happy-kitchen-89482, relates to our convo yesterday about interpreter constraints

That's true. I had my default constraints set up like that (

==3.6.*

and

==3.8.*

) but that messed up building one wheel for all of those. So I switched to

>=3.6,<3.9

. the pants-plugins resolve is the exception - I don't care much about the constraints for it, I just want it compatible with pants. (Aside: a shortcut constraints keyword similar to the

pants_requirements

target that looks up its value based on the version of pants in pants.toml would be really nice. That would simplify the pants-plugins resolve config so I don't have to manually track what pants requires) But, back to your point about testing multiple versions: we run tests (for code in our default resolve) on 3.6 and 3.8. It's not clear how I'll accomplish that (once pants can run our tests). For CI, I'm going to only install the target version of python and maybe manipulate the search paths to ensure the version of python I want is selected. On my local machine, that will be more awkward as I have installs of lots of different versions of python including every minor (not patch) version from 3.4 to 3.11 plus 2.7. So, a more standardized way to specify which interpreter(s) to use for tests would be excellent.

isn’t the interpreter_constraints a list value? and multiple values `OR`’d together? if so, we could use that list as your “test matrix”. If you just want a single run, use a single value:

[">=3.6,<3.9"]

, but if you want to test with multiple versions go with multiple ICs instead:

["==3.6.*", "==3.7.*", ">=3.8,<3.10", …]

Oh my ... consider the OR broken, even though it is supported. That is a legacy holdover that needs to go away.

If you just want a single run, use a single value: [">=3.6,<3.9"], but if you want to test with multiple versions go with multiple ICs instead: ["==3.6.*", "==3.7.*", ">=3.8,<3.10", …]

Yes. That doesn't work. I need my wheel to have one IC, but I want to test with multiple. So, would I have to parametrize all of my python_tests to use the list instead of the single constraint?

Oh that's a good idea. I think it's feasible, although requires some refactoring because IC resolution now needs access to another field on the target. Feasible, but boilerplatey

As Eric alluded, I am rethinking the complexity around ICs (and, to a lesser extent, resolves), so this is great feedback.

@happy-kitchen-89482 here's someone else who was confused by the separate IC config in

pants.toml

vs

BUILD

. https://github.com/pantsbuild/pants/issues/16566#issuecomment-1366593885

Thanks, yes, ICs are a hot mess right now. I think I will start by documenting that they must be specified explicitly, then enforcing that they must be.

@happy-kitchen-89482 Are you thinking of removing

[python].interpreter_constraints

and

[python.resolves_to_interpreter_constraints]

from

pants.toml

? And just collecting the relevant info from all the BUILD files? That could work too.

But, IIRC not all targets currently support ICs. Just

pex_binary

?

python_test*

and

python_source*

and

python_distribution

and friends support it.

Ok then, could work.

I think Benjy's (very tentative!) proposal is instead to get rid of the field and have ICs come from the target's resolve. If you're not using resolves, ICs come from an option and you can only have one set of ICs in the repo This aligns with a proposal both Stu and I advocate for, named interpreter constraints: https://github.com/pantsbuild/pants/issues/12652. One of my main motivations is it is currently too easy for a dev to add new ICs to their repo without an admin knowing. That typically results in lots of new complexity, so it should be less easy to define new unique ICs

@enough-analyst-54434 I think pushing more into BUILD files is the way to go, though I don't think everything will end up there. Some things are really settings for pants itself, and have nothing to do with BUILD metadata. Things like anonymous telemetry, or cli colors. So, I think there will continue to be a separation between the two types of config files, but the dividing line could be brighter/clearer on what to find in each.

Why can't build metadata be in toml. Why two formats?

I can see tying ICs to the resolve. That makes sense the way I was initially trying to use it.

Or vice versa

Why can't build metadata be in toml. Why two formats?

Ah. true. The main pants config file could also be python-esque. TOML is a lot more restrictive, so I wouldn't want it in BUILD files where the expressive syntax of python is very useful. And having something with a more limited syntax, like toml, to define the version of pants to use is helpful because you can more easily scrape settings like that with bash+grep+etc.

Yeah, pants.toml existing at all, rather than as a top-level BUILD file, is a continuation of historical accident

Very nice. I look forward to developments here 🙂

Will be airing ideas (and grievances...) in public 🙂