Regression for 3.13t virtual environments created with uv on Windows

[zanieb]

Upgrading to the latest release, the python.exe uv creates for virtual environments is broken, presumably because of #373.

.venv/Scripts/python --version
did not find executable at 'C:\Users\runneradmin\AppData\Roaming\uv\python\cpython-3.13.1+freethreaded-windows-x86_64-none\python3.13t.exe': The system cannot find the file specified.

[source]

I presumed this was because sys._base_executable was returning the old path (python3.13t.exe), however, it looks correct in the tests I'm running. I'm not sure what is causing the incorrect path, but it was working with the previous python-build-standalone distribution.

I'm testing the standard library venv module too.

Out of an abundance of caution, I've marked 20241205 as a pre-release until the cause is known.

[zanieb]

I ran into another error when attempting to use python -m venv:

Run & (./uv python find 3.13t) -m venv .venv
Error: Command '['D:\\a\\uv\\uv\\.venv\\Scripts\\python.exe', '-m', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 103.

[source]

This does not occur using the previous distribution; see https://github.com/astral-sh/uv/pull/9665

[zanieb]

After further investigation, the issues are resolved by creating a copy of python.exe at python3.13t.exe (as I did initially). I still don't understand the root cause of the issue though. It's quite painful to debug the issue on Windows remotely.

I may release #406 as a quick solution to get the Python security releases out.

[zooba]

The target executable name is baked into the venvlauncher.exe that's under Lib\venv\scripts\nt. So if you move the 3.13t.exe then the script that's copied into a venv won't find it.

The best approach is to override the filename during build (patch PyExeName property in python.props or pass /p:PyExeName=python.exe to MSBuild - we could take a patch upstream to allow the PyExeName environment variable to also work, but right now it'll be overridden).

Otherwise, if you replace the venvlauncher_t.exe script with the venvlauncher.exe one, they'll both try to launch python.exe and not python3.13t.exe. This is probably less reliable than overriding the name during build, but it may be easier.

[zanieb]

Thank you @zooba — that saves me a bunch of time <3

[zanieb]

Now, the question is whether we want to make that change now or just create a copy of the executable (as in the open pull request). I'm leaning towards the latter, but without strong justification — it just lets us get the security release out sooner.