site emits two spurious RuntimeWarnings when a venv interpreter is started via a non-normalized path (3.14 regression)

Bug report

Bug description:

Current behavior

Since 3.14, starting a virtual environment's interpreter through a non-normalized path makes site emit two spurious RuntimeWarnings on every process start:

python3.14 -m venv /tmp/v
mkdir -p /tmp/sub && cd /tmp/sub
../v/bin/python -c "import sys; print(sys.prefix)"

<frozen site>:101: RuntimeWarning: Unexpected value in sys.prefix, expected /tmp/v, got /tmp/sub/../v
<frozen site>:101: RuntimeWarning: Unexpected value in sys.exec_prefix, expected /tmp/v, got /tmp/sub/../v
/tmp/sub/../v

Expected behavior

No warning. /tmp/v and /tmp/sub/../v are the same directory. Only the spelling differs, and there is no action the user can take in response.

Bisection

Clean venvs, invoking ../v/bin/python from a sibling directory:

version	warnings	sys.prefix
3.11.15, 3.12.13, 3.13.15	0	/tmp/v
3.14.7, 3.15.0rc1	2	/tmp/sub/../v

sys.executable is identical on all five (/tmp/sub/../v/bin/python). Only sys.prefix and the check are new.

Cause

site._venv() compares a sys.prefix that is not normalized against a site_prefix that is:

exe_dir = os.path.dirname(os.path.abspath(executable))   # abspath() normalizes
site_prefix = os.path.dirname(exe_dir)
...
if sys.prefix != site_prefix:
    _warn(f'Unexpected value in sys.prefix, expected {site_prefix}, got {sys.prefix}',
          RuntimeWarning)

Up to 3.13 that line was an assignment, sys.prefix = sys.exec_prefix = site_prefix, so the normalized value won and nothing could disagree. GH-126987 (gh-126985), by Filipe Laíns, turned it into a consistency check while moving pyvenv.cfg detection into getpath. sys.prefix now comes from getpath, which does not normalize. The check is worth keeping, since it catches a real disagreement, and the tests below keep it doing that. Only the string comparison is too strict.

The abspath() on the other side is not incidental. It was added in #60723 (bpo-16519, 2012), reported by Christian Heimes and fixed by Vinay Sajip, specifically so that invoking the interpreter through a relative path would work, the same shape of invocation as above. That fix still does its job. What is new is that the other side of the comparison no longer goes through it.

Both sides derive from the same executable and differ only by that abspath():

sys.prefix  = dirname(dirname(         executable ))   # getpath.py:322, 352-353, 656
site_prefix = dirname(dirname( abspath(executable)))   # site.py:973-974

Suggested fix

Compare normalized forms:

if os.path.normpath(sys.prefix) != site_prefix:

and likewise for exec_prefix. No observable value changes. sys.prefix, sys.exec_prefix and sys.executable are all left as they are, and the message still reports the original value. Only the condition for warning changes.

This does not weaken the check. On a build of main (eb08902), only the false positives change, and every genuine mismatch still warns, including the one from #154160.

Every case, measured with and without the change

case	before	after
../v/bin/python from a sibling directory	2	0
the same with env -i (no PATH in the environment)	2	0
relative PATH entry (the #154160 symptom)	2	2
absolute invocation	0	0
//tmp/v/bin/python	0	0
.. in the middle of the path	0	0
pyvenv.cfg next to the interpreter	2	2

os.path.normpath is a C builtin and the comparison only runs inside a venv, so the cost is around 1 µs per interpreter start. I could not measure it above noise end to end.

I have a patch with two tests, since there is currently no test for this warning in test_site.py or test_venv.py, plus a NEWS entry. Happy to open a PR.

Related, but not duplicates

• #58296 and #75213 ask for sys.executable and the prefixes to be canonicalized. That was declined, and this report does not ask for it. It starts from that decision. Victor Stinner's "the path is not required to be normalized" in #58296 is the premise here: precisely because a non-normalized sys.prefix is accepted behaviour, comparing it with != against a normalized path is the wrong test. The bisection supports that reading, since sys.executable is unchanged from 3.11 through 3.15 and only the comparison is new.
• #154160 / GH-154163: Peter Wu's report shows these same two warnings in its output, so it ran into the symptom first. I only noticed afterwards that they can also be reached without PATH being involved at all. It is a different branch of Modules/getpath.py, reached only when program_name has no separator, so Vyron Vasileiadis' fix there does not cover this case. With env -i, where ENV_PATH is empty and that branch is unreachable, the warnings still appear. Conversely, nothing suggested here affects the relative-PATH symptom reported there. The two changes are independent, and neither makes the other redundant.

Found via a shell script that did cd subdir && ../venv/bin/python …, which put two warning lines at the top of every log it produced.

Since this is a 3.14 regression, a backport may be appropriate, but I will leave that call to you.

CPython versions tested on:

CPython main branch, 3.11, 3.12, 3.13, 3.14, 3.15, 3.16

Operating systems tested on:

Linux

Linked PRs

• gh-156496

Comece em Lib/site.py, em _venv, e revise a cobertura relacionada em Lib/test/test_site.py e Lib/test/test_venv.py, juntamente com a entrada de NEWS mencionada no relatório. Execute os casos de inicialização do venv do issue e confirme que os avisos de falsos positivos desaparecem, enquanto as incompatibilidades genuínas continuam gerando avisos; gh-156496 já está vinculado.