I'm running into a problem running

./pants :: test --test-use-coverage --print-stacktrace

. After my tests pass I get an error saying invalid syntax. It seems like python3.7 which was used to bootstrap pants doesn't understand my

with (
 open(...) as a,
 open(...) as b
):

syntax. I would have expected coverage to use

python3.10

as I set

[python]
interpreter_constraints = ["CPython==3.10.*"]

Full Error is

Engine traceback:
  in select
  in pants.core.goals.test.run_tests
  in pants.backend.python.goals.coverage_py.generate_coverage_reports
Traceback (most recent call last):
  File "/home/yjabri/.cache/pants/setup/bootstrap-Linux-x86_64/2.14.1_py37/lib/python3.7/site-packages/pants/engine/internals/selectors.py", line 653, in native_engine_generator_send
    res = func.send(arg)
  File "/home/yjabri/.cache/pants/setup/bootstrap-Linux-x86_64/2.14.1_py37/lib/python3.7/site-packages/pants/backend/python/goals/coverage_py.py", line 572, in generate_coverage_reports
    keep_sandboxes=keep_sandboxes,
pants.engine.process.ProcessExecutionFailure: Process 'Generate Pytest report coverage report.' failed with exit code 1.
stdout:
Couldn't parse '/tmp/pants-sandbox-QX6Xdr/foo/tests/bar.py' as Python source: 'invalid syntax' at line 190

stderr:



Use `--keep-sandboxes=on_failure` to preserve the process chroot for inspection.

That looks like buggy behavior indeed. You can work around by configuring: + https://www.pantsbuild.org/docs/reference-coverage-py#interpreter_constraints + https://www.pantsbuild.org/docs/reference-coverage-py#lockfile And then running

pants generate-lockfiles --resolve=coverage-py

I tried adding just

[coverage-py]
interpreter_constraints = ["CPython==3.10.*"]

and that seems to work. I don't know enough about lockfiles to know why it'd be a good idea / required here.

That's another bug then. A lockfile is used internally: https://github.com/pantsbuild/pants/blob/main/src/python/pants/backend/python/subsystems/coverage_py.lock You really should regenerate the lock.

Interesting. For what it's worth I'm using

pants_version = "2.14.1"

Let me see if it still happens when I change it to

2.15.0

Ok. Yeah, changing lock inputs, of which ICs are one, should invalidate the lock and lead to an error asking you to re-generate the lock.