Hey, y’all! Quick question regarding multiple python versions/interpreter constraints on CI. Does Pants offer a way of running goals for specific constraints (i.e. running

test

only for sources that fit into some specific constraint)? Maybe some kind of

--filter-python-interpreter

for python interpreters or something like that? Does that even make sense? 🤔 Context: we have introduced new sources with different Python constraints on our monorepo and are now trying to see what would be the best way to adjust our CI. The options we’ve considered are: • Make sure the image in which our CI step runs has all Python versions available (similar to what we have on the local environment with pyenv) • Have different steps that

--filter

tests for specific constraints, each one running on an image with a single python version required for those tests

leveraging

tags

comes to mind…

thanks, @curved-television-6568! Haven’t considered that initially, but it might work! Let me check it here. BTW, I had a small feeling that the interpreter discovery process happened before the filtering of the targets, but couldn’t check it yet. Do you know whether that’s the case or not?

I’m pretty sure there’s no interpreter discovery done for the targets in question until after any filtering have been applied. Other rules may invoke tools or rules that need an interpreter which may make it seem like there’s interpreter discovery going on, but would be unrelated (or only tangentially related)

We are currently running into a weird behavior, but I’m not 100% sure whether this is something on our side or if that’s a bug. Here is the command we are currently running 👇

./pants --changed-since=origin/main
        --changed-dependees=transitive
        --filter-address-regex="folder/with/only/python310/code/*"
        --filter-target-type=pex_binary 
      package

Assuming that all changed code (and their dependents) also live within the

folder/with/only/python310/code

folder, I would expect this to work on an environment with Python 3.10 only. However, the behavior we see right now is that, even though the code that requires a different python version (3.8.*) has not changed and is also under a different folder, we still receive the

No interpreter compatible

error 👇

Examined the following interpreters:
1.) /usr/local/bin/python3.10 CPython==3.10.12
2.)        /usr/bin/python3.9 CPython==3.9.2

No interpreter compatible with the requested constraints was found:

  Version matches CPython==3.8.*

It’s important to notice that we don’t have

python_sources

or

pex_binaries

that depend on any of the sources that require the 3.8.* interpreter.

to double check, what do you get with

peek

instead of

package

(and then pipe through

jq

):

❯ pants [all your options] peek | jq -r 'map(.interpreter_constraints)|.[]|.[]?' | sort | uniq

our

pex_binaries

that result from these filters don’t have direct interpreter_constraints defined to them (they inherit the global defined on

*<http://pants.to|pants.to>*ml

, so this command returns only

nulls

thanks for the repro, very helpful.

Thanks for the help, Andreas! I’ll fill the bug report 😃