Skip to content

feat: Support python.exe fallback on Windows #2919

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

esafak
Copy link
Contributor

@esafak esafak commented Jul 31, 2025

On Windows, when discovering Python interpreters via PEP 514, if the ExecutablePath is not present in the registry, the discovery mechanism will now look for python3.exe first, and then fall back to python.exe.

This allows virtualenv to discover Python on Windows installations that use the python.exe executable name.

Fixes #2774

  • ran the linter to address style issues (tox -e fix)
  • wrote descriptive pull request text
  • ensured there are test(s) validating the fix
  • added news fragment in docs/changelog folder
  • updated/extended the documentation

On Windows, when discovering Python interpreters via PEP 514, if the `ExecutablePath` is not present in the registry, the discovery mechanism will now look for `python3.exe` first, and then fall back to `python.exe`.

This allows virtualenv to discover Python on Windows installations that use the `python.exe` executable name.

Fixes pypa#2774

Signed-off-by: Emre Şafak <[email protected]>
gaborbernat
gaborbernat previously approved these changes Aug 1, 2025
@gaborbernat gaborbernat enabled auto-merge (squash) August 1, 2025 00:04
On Windows, when discovering Python interpreters via PEP 514, if the `ExecutablePath` is not present in the registry, the discovery mechanism will now look for `python3.exe` first, and then fall back to `python.exe` for Python 3, and only `python.exe` for Python 2.

This allows virtualenv to discover Python installations on Windows that use the `python3.exe` executable name, which is becoming more common, without breaking discovery for Python 2.

A test case has been added to verify this new behavior. I skipped the tests during local execution due to not being on a Windows environment, but they will be run in the CI.
auto-merge was automatically disabled August 1, 2025 00:13

Head branch was pushed to by a user without write access

@gaborbernat gaborbernat marked this pull request as draft August 1, 2025 01:03
On Windows, when discovering Python interpreters via PEP 514, if the `ExecutablePath` is not present in the registry, the discovery mechanism will now look for `python3.exe` first, and then fall back to `python.exe` for Python 3, and only `python.exe` for Python 2.

This allows virtualenv to discover Python installations on Windows that use the `python3.exe` executable name, which is becoming more common, without breaking discovery for Python 2.

A test case has been added to verify this new behavior.
On Windows, when discovering Python interpreters via PEP 514, if the `ExecutablePath` is not present in the registry, the discovery mechanism will now look for `python3.exe` first, and then fall back to `python.exe` for Python 3, and only `python.exe` for Python 2.

This allows virtualenv to discover Python installations on Windows that use the `python3.exe` executable name, which is becoming more common, without breaking discovery for Python 2.

A test case has been added to verify this new behavior.

chore: Add logging to aid debugging test failures
On Windows, when discovering Python interpreters via PEP 514, if the `ExecutablePath` is not present in the registry, the discovery mechanism will now look for `python3.exe` first, and then fall back to `python.exe` for Python 3, and only `python.exe` for Python 2.

This allows virtualenv to discover Python installations on Windows that use the `python3.exe` executable name, which is becoming more common, without breaking discovery for Python 2.

A test case has been added to verify this new behavior.
On Windows, when discovering Python interpreters via PEP 514, if the `ExecutablePath` is not present in the registry, the discovery mechanism will now look for `python3.exe` first, and then fall back to `python.exe` for Python 3, and only `python.exe` for Python 2.

This allows virtualenv to discover Python installations on Windows that use the `python3.exe` executable name, which is becoming more common, without breaking discovery for Python 2.

A test case has been added to verify this new behavior.
@gaborbernat
Copy link
Contributor

Marked this as a draft for now 🚧—let’s get the CI sorted, and then feel free to mark it ready for review! 😊

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

python3.exe missing on windows when creating a virtualvenv
2 participants