Repository navigation
venv.EnvBuilder creates inconsistent venv depending on the name of the Python executable #122033
Description
Bug report
Bug description:
Given the below create-venv.py script and several Python 3 installed in the classpath:
import sys
import venv
if __name__ == "__main__":
venv.EnvBuilder().create(sys.argv[1])Let’s create various venvs:
for VERSION in 3.9 3.11 3.12; do
python$VERSION create-venv.py $VERSION-venv
for EXEC in python python3 python$VERSION; do
$VERSION-venv/bin/$EXEC create-venv.py $VERSION-$EXEC-venv
done
doneAnd now, let’s check them:
for PYTHON in *-venv/bin/python; do
echo "$PYTHON: $($PYTHON --version)"
doneThe above loop outputs:
3.11-python3.11-venv/bin/python: Python 3.11.7
3.11-python3-venv/bin/python: Python 3.9.14
3.11-python-venv/bin/python: Python 3.9.14
3.11-venv/bin/python: Python 3.11.7
3.12-python3.12-venv/bin/python: Python 3.12.1
3.12-python3-venv/bin/python: Python 3.9.14
3.12-python-venv/bin/python: Python 3.9.14
3.12-venv/bin/python: Python 3.12.1
3.9-python3.9-venv/bin/python: Python 3.9.14
3.9-python3-venv/bin/python: Python 3.9.14
3.9-python-venv/bin/python: Python 3.9.14
3.9-venv/bin/python: Python 3.9.14
As the reader can see, Python venv’s created by python or python3 executable of a Python venv will not use the Python of this venv, and instead will use the system’s default Python (3.9 in my case).
CPython versions tested on:
3.11, 3.12
Operating systems tested on:
Oracle Linux 9 and 10
Activity
FFY00 commentedon Jul 22, 2024
This happens because it likely copies/symlinks the interpreters from
PATH, which points to the wrong versions as the venv is not active. We could prefer to copy them from thescriptspath of the running interpreter, but I am wary of that as some people might be relying on the current behavior.gaborbernat commentedon Jun 5, 2026
I can't reproduce this on 3.11–3.16, across uv standalone builds, homebrew framework builds, and a source build, even with a different
python3placed first onPATH: in every case the inner venv'ssys._base_executableresolves to the running interpreter's base and the new venv inherits the right version. It looks specific to how the interpreters were installed rather than to the Python version, and the report doesn't include enough detail to reproduce it.Recommend closing as not reproducible. It can be reopened with a minimal reproducer — the OS and exact install method (distro packages, pyenv/deadsnakes, source) and whether it still happens on 3.13/3.14.
EtienneMiret commentedon Jul 21, 2026
This was originally on Oracle Linux 9. I can still reproduce it on Oracle Linux 10. Could be a bug specific to the packaging though.
See https://github.com/EtienneMiret/cpython-122033 for an MCVE using Docker.
picnixz commentedon Jul 21, 2026
cc @FFY00
pythongh-122033: Cover versioned copied virtualenv executables
zanieb commentedon Aug 13, 2026
We just got a report of this in uv.
Unfortunately, this seems hard to fix without adding additional metadata to
pyvenv.cfg. I thought maybe we could makegetpathrespectexecutable, but that will cause problems because it's canonicalized.zanieb commentedon Aug 13, 2026
If we do #129382 then the incidence of this will likely be greatly reduced though