René's URL Explorer Experiment

Title: gh-128670: keep the public base executable when creating a venv from a venv by gaborbernat · Pull Request #150999 · python/cpython · GitHub

Open Graph Title: gh-128670: keep the public base executable when creating a venv from a venv by gaborbernat · Pull Request #150999 · python/cpython

X Title: gh-128670: keep the public base executable when creating a venv from a venv by gaborbernat · Pull Request #150999 · python/cpython

Description: Problem When a virtual environment is created from inside another virtual environment, and the base interpreter is reached through a stable public symlink, the child environment records the internal, version-stamped target in its pyvenv.cfg home instead of the stable public path. This happens with the common ways people now get Python: Homebrew — the stable …/opt/python@3.x/bin path resolves to a versioned …/Cellar/python@3.x/3.x.y/… path; relocatable / uv-managed interpreters and NFS canonical paths. When that internal path later changes — a Homebrew patch upgrade deletes the old Cellar/3.x.y tree, an NFS mount moves — the recorded home dangles and the environment breaks. The public symlink exists precisely so callers don't depend on the internal path, so baking it in defeats the purpose. Reproduction (Linux; also reproduces on Homebrew 3.12–3.14): $ mkdir -p /pub/bin && ln -s /usr/local/bin/python3.x /pub/bin/ $ /pub/bin/python3.x -m venv /v1 $ /v1/bin/python -m venv /v2 $ grep home /v1/pyvenv.cfg # home = /pub/bin (public, kept) $ grep home /v2/pyvenv.cfg # home = /usr/local/bin (internal — bled through) Solution In getpath's pyvenv.cfg home branch, when computing base_executable, prefer the executable as named in home (the public location the venv was created from) when it resolves to the same real file as the running interpreter, instead of fully resolving the symlink. Fall back to the previous fully-resolved path when home has no matching executable or it points elsewhere. The candidate is looked up by the resolved interpreter's name, since a venv's primary executable is python while home may only provide python3.x. This is the getpath-feasible form of what uv settled on (astral-sh/uv#8433) and corrects #128913, which matched on python and so missed the common python3.x-only case. Why it's safe Exactly one behaviour changes: a venv-from-venv whose base is reached via a public symlink now records the public path. Non-symlinked bases, a home with no matching executable, and a home pointing at a different file all produce the identical result as before. Guarded: the public path is kept only if it exists and resolves to the same real file as the running interpreter, so base_executable is never pointed at a missing or different binary. Stdlib resolution is untouched: base_prefix and the standard-library search run afterward as before and still resolve to the real location — the created environments run with the correct base_prefix (verified end-to-end). Validated: four new test_getpath cases (public symlink, versioned-name, mismatch-guard, no-home-exe fallback) plus test_getpath/test_venv and a broader sweep (test_embed, test_site, test_sysconfig, test_subprocess) — 654 tests, no regressions; and end-to-end on Linux across single-hop, multi-hop, and a 3-level venv chain. Issue: gh-128670

Open Graph Description: Problem When a virtual environment is created from inside another virtual environment, and the base interpreter is reached through a stable public symlink, the child environment records the interna...

X Description: Problem When a virtual environment is created from inside another virtual environment, and the base interpreter is reached through a stable public symlink, the child environment records the interna...

Opengraph URL: https://github.com/python/cpython/pull/150999

X: @github

direct link

Domain: github.com

Links:

Viewport: width=device-width