When I build from source (main) using a VSCode dev container, it installs Python 3.11 on Debian “bookworm”-based image, but there are a bunch of tests that have a constraint for Python<3.10 and fail. Example for

src/python/pants/backend/python/util_rules/local_dists_pep660_test.py::test_build_editable_local_dists

below. Happy to submit a PR with a steer on what’s expected. I would think that on main branch the lockfile would match 3.11.

E       pants.engine.process.ProcessExecutionFailure: Process 'Find interpreter for constraints: CPython<3.10,>=3.8' failed with exit code 1.
E       stdout:
E       
E       stderr:
E       Could not find a compatible interpreter.
E       
E       Examined the following interpreters:
E       1.)                                                                                                                 /usr/local/python/3.11.11/bin/python3.11 CPython==3.11.11
E       2.) /home/vscode/.cache/pants/named_caches/pex_root/venvs/1/c614f2526bee25dbcb5f1c6240bbc6c2ffcefcb2/fde881b08d139e77c5884cc86de1fb5369b6b82c/bin/python3.11 CPython==3.11.11
E       3.)                                                                                                                                      /usr/bin/python3.11 CPython==3.11.2
E       4.)                                                                                                                                     /usr/bin/python3.11d CPython==3.11.2

Re tests not matching Pants’s own Python interpreter version, that is by design. 3.11 happens to be what Pants uses as an internal implementation detail, but that’s unrelated to the version of Python that the user code will require.

I ran into stuff like this a few times - but it applies for a lot of our tests. My gut feel is that our tests should skip if some dependencies aren't in the environment (e.g. docker) - and in CI, that should be a failure

Just FYI, I am seeing weird errors with things like, say, assumptions about

awk

version for some failing tests. I’m going to patch up the dev container so it all passes, but my observation is that there do seem to be assumptions about the local environment which would need to be either documented or automated via a dev container if unit tests are to work “out of the box” in local.

Whoa, awk - wouldn't have seen that one coming

awk is like the Spanish Inquisition: nobody expects it.

What I do at $DAYJOB is have the devcontainer and CI image be the same image. I'm not sure of if the magical GitHub Action images are usable in that way.

It’s actually something I thought about contributing: I have done a CI job before that builds and pushes a container using dev container CLI GitHub actions, including using QEMU to build ARM64 images for MacOS, and act feature can be used in local dev container to test GitHub Actions too. What you suggest is the ideal, though probably would require some careful testing before using in main CI. Maybe start by just build dev container image.