Description
Summary
The following sequence reproduces something I noticed:
mkdir p1
mkdir p2
cat > p1/pyproject.toml <<EOF
[project]
name = "p1"
version = "0.0.0"
dependencies = ["aiofiles"]
EOF
cat > p2/pyproject.toml <<EOF
[project]
name = "p2"
version = "0.0.0"
dependencies = ["requests"]
EOF
cat > main.py <<EOF
import sys
print(f"Python is {sys.executable}")
EOF
mkdir build
mkdir build/p1
mkdir build/p2
pushd p1
UV_PROJECT_ENVIRONMENT=../build/p1 uv sync
UV_PROJECT_ENVIRONMENT=../build/p1 uv run --no-sync --with pip ../main.py
popd
pushd p2
UV_PROJECT_ENVIRONMENT=../build/p2 uv sync
UV_PROJECT_ENVIRONMENT=../build/p2 uv run --no-sync --with pip ../main.py
popd
The script main.py prints the current interpreter. Each of the uv run statements ends up printing the same interpreter, with the contents of _uv_ephemeral_overlay.pth changing in between the statements.
I don't know if this is a bug, but it was surprising to me. When I don't use --with pip, the venvs are the separate venvs in build/p1 and build/p2.
My motivating use case is that I am using UV_PROJECT_ENVIRONMENT to isolate separate venvs in order to build multiple members of my workspace. When I build them in parallel, the shared ephemeral venvs clobber each other in unpredictable ways. I wonder if maybe I should be approaching this problem in a different way?
Platform
Darwin 24.3.0 arm64
Version
uv 0.6.14
Python version
Python 3.13.0