How can I override the global

interpreter_constraints

on

python_distribution

? Globally I have

interpreter_constraints = ["==3.8.*", "==3.9.*"]

which pants refuse when `package`ing:

SetupPyError: Expected a single interpreter constraint for libs/image_augmentation:kaiko-image-augmentation-dist, got: CPython==3.8.* OR CPython==3.9.*.

Makes sense, so setting this

defaults

in the top-level build file:

__defaults__(
    {
        python_distribution: dict(interpreter_constraints=["==3.8.*"]),
    }
)

I obtain

SetupPyError: Expected a single interpreter constraint for libs/image_ml:kaiko-image-ml-dist, got: CPython==3.8.* OR CPython==3.8.*,==3.9.*.

which looks weird to me, because it means the two fields are ORed, whereas I'm expecting

__defaults__

to override the value. At this point there's a nice hint saying to translate the conjunction using exclusions, so I changed the

_defaults_

above to

!=3.9.*

. Then it fails with:

Expected a single interpreter constraint for libs/image_augmentation:kaiko-image-augmentation-dist, got: CPython!=3.9.*,==3.8.* OR CPython!=3.9.*,==3.9.*.

which looks like I'm almost there if pants was trimming unsatisfiable disjunctions 😉 What else can I do 🙏 ?

I haven't been following all of the interpreter discussions, but would:

["CPython>=3.8,<3.10]"

work?

Yes it does ❤️ This is quite puzzling, since

["CPython>=3.8,<3.10]"

and

["==3.8.*", "==3.9.*"]

are semantically equivalent.. But that's a whole different story without an arithmetic solver under the hood 😞

I think if it's confusing, there should be an issue - it might be doc-centric? But maybe there is a bug? I'm not going to claim to know. I'm still grokking how all the ICs interact

@lemon-oxygen-72498 the affordance for OR was added purely for Twitter internal needs back in the Pants v1 days. They never actually needed the feature and could've spelled what they needed with a range + `,!=X,!=Y,`etc. Unfortunately that is still lying around and is really legacy. Although this is certainly a bug, be warned - best to stay away from use of the OR facility. It is non-standard in the Python world and non-standard will always get you in the end.

I see, well I blame no one, the ecosystem and list of PEPs can be hard to track 😄

Well, if anyone should be tracking its folks writing a build tool for the language! You're more forgiving than I.

Well tooling people are usually far from the frontline, so they look like they are not bringing money in to deciders. As a consequence tooling teams are regularly under staffed. Makes it tricky to ship a bulletproof thing.

whereas I’m expecting

__defaults__

to override the value.

I’m not sure about what’s going on, only that

__defaults__

as such does override the value on

python_distribution

(try to verify what you get if you set the value explicitly on the target, I would expect the same outcome) Is it not that you have interpreter constraints from your global config on the

python_sources

targets, and then the ICs from defaults on the

python_distribution

targets, and the interplay is how Pants treats them when they’re not aligned..?

try to verify what you get if you set the value explicitly on the target, I would expect the same outcome

Yes I had tried it and indeed I had the same outcome 👍

then the ICs from defaults on the

python_distribution

targets, and the interplay is how Pants treats them when they’re not aligned..?

Yes this is also my understanding in the end. The "bug" is that pants doesn't reduce the interpreter constraints as much as I expected it would, yielding a disjunction of two constraints, whereas it could yield a single constraint.