#23461 Pants 2.32.1 uv resolver intermittently creates incompatible venv_cache during requirements.pex build Issue created by sigurduraegir We are seeing intermittent CI failures after upgrading from Pants 2.32.0 to 2.32.1. The project uses:

[python]
  enable_resolves = true
  resolver = "uv"
  interpreter_constraints = ["CPython>=3.13,<3.14"]


  [python.resolves]
  python-default = "3rdparty/default.lock"

The failure happens most frequently before tests run, while Pants is building requirements.pex. Example failure from

pants test ::

ProcessExecutionFailure: Process 'Building 12 requirements for
requirements.pex from the 3rdparty/default.lock resolve: ...' failed with
exit code 1.

Using CPython 3.13.13 interpreter at: /usr/local/bin/python3.13


error: Project virtual environment directory
`/root/.cache/pants/named_caches/venv_cache/.../python-default/...`
cannot be used because it is not a compatible environment but cannot be
recreated because it is not a virtual environment

Resolve from venv at .cache/venv_cache/... failed:
The virtual environment does not have aws-lambda-powertools installed but it
is required by top level requirement aws_lambda_powertools>=3.29.0

We have seen the same error in multiple pipelines, with different missing top-level requirements, for example base32-lib in one run and aws-lambda-powertools in another. Important observations: • The failures started after a we changed pants_version from 2.32.0 to 2.32.1. • Removing Bitbucket Pipeline cache wiring did not fix it. • The failing step was not restoring a Bitbucket cache. • Re-running the same pipeline can pass. • This also happens when running "pants lint ::", but less frequently. • Pinning Pants back to 2.32.0 appears to avoid the failure so far. • Running pants tests with

pants --process-execution-local-parallelism=1 test ::

might address the issues, but it makes our test suite unacceptably slow. Due to the intermittent nature of the issue, I am not 100% sure that this is a true fix. This might be related to the 2.32.1 change for #23344, where uv venv creation was moved into the same process as the PEX build via CompositeProcess. In 2.32.0, uv venv creation ran as a separate process. In 2.32.1, create_venv_repository_from_uv_lockfile() returns a creation_subprocess, and build_pex() prepends it to the PEX build process. Our failures now occur inside the Building requirements.pex process, which matches that change. Hypothesis (highly speculative): with concurrent PEX builds using the same resolve/interpreter/buildroot, multiple uv sync subprocesses may target the same UV_PROJECT_ENVIRONMENT under venv_cache. Sometimes uv sees a partially-created or incompatible directory and fails with “not a virtual environment”. pantsbuild/pants