test_isolation calls subprocess.check_call without env=, so the parent's PYTHONPATH leaks into the isolated venv. The test expects import build.env to fail inside the venv, but it succeeds because build is reachable via PYTHONPATH.
This wasn't visible before 1.4.3 because eager imports in build/init.py would pull in pyproject_hooks, which isn't in the venv, causing the import to fail for a different reason. The lazy_modules added in 1.4.3 defers that import on Python 3.15, unmasking the PYTHONPATH leak.
Suggested fix: use make_extra_environ() (which already clears PYTHONPATH) for the subprocess:
@@ -3,6 +3,7 @@
import importlib.util
import logging
+import os
import shutil
import subprocess
@@ -52,7 +53,8 @@
debug = 'import sys; import os; print(os.linesep.join(sys.path));'
with build.env.DefaultIsolatedEnv() as env,
pytest.raises(subprocess.CalledProcessError):
- subprocess.check_call([env.python_executable, '-c', f'{debug} import build.env'])
+ isolated_env = {**os.environ, **env.make_extra_environ()}
+ subprocess.check_call([env.python_executable, '-c', f'{debug} import build.env'],
env=isolated_env)
test_isolation calls subprocess.check_call without env=, so the parent's PYTHONPATH leaks into the isolated venv. The test expects import build.env to fail inside the venv, but it succeeds because build is reachable via PYTHONPATH.
This wasn't visible before 1.4.3 because eager imports in build/init.py would pull in pyproject_hooks, which isn't in the venv, causing the import to fail for a different reason. The lazy_modules added in 1.4.3 defers that import on Python 3.15, unmasking the PYTHONPATH leak.
Suggested fix: use make_extra_environ() (which already clears PYTHONPATH) for the subprocess: