When should `venv/scripts/nt/python.exe` be present?

Hi there!

Our virtualenv creator operates by copying {stdlib}/venv/scripts/nt/python.exe and {stdlib}/venv/scripts/nt/pythonw.exe from the parent interpreter. We recently received a report that we were failing to create virtualenvs on Windows in Python 3.13 (in GitHub Actions, specifically).

I installed a few distributions locally from python.org, and noticed that while these executables exist in Python 3.10, 3.11, and 3.12, they do not exist in Python 3.13, and instead, venvlauncher.exe and venvwlauncher.exe are present in that directory. (Meanwhile, venvlauncher.exe and venvlauncherw.exe do not exist in Python 3.10, 3.11, and 3.12, at least when installed via python.org).

If this is intentional, that’s fine – mostly just looking for clarity on what we should expect to exist in that directory. (If it’s not intentional, then consider it a bug report :))

Have you tried using another tool to create a virtual environment (perhaps the built-in venv module) and seeing how the result is structured on Windows?

I’ve never heard of virtual environments - or base Python installations, for that matter - having a nt subfolder within scripts. It’s been a few years since I used Windows, but I’m quite sure my older Python installations weren’t organized like that.

The filename has just changed in 3.13, that’s all. They get renamed when being copied into place.

It made sense because of the extra handling needed for free-threaded builds, which need different executables (though those will only be included when the build option and installer option were used).

In terms of clarifying what you can expect:

  • you can expect whatever is present in 3.13.0 beta 1 to be present in 3.13.0, because that’s when we stop changing the file system layout of a typical install
  • you can rely on python -m venv doing the right thing. Everything else is internal implementation :wink:
1 Like

Internal implementation, alas! Hah, okay, thank you, I appreciate the quick response.