fix: always use copies for the isolated venv on Windows - #1176
Merged
Conversation
Version 1.6.0 fixed the symlink probe (pypa#1118), so isolated environments on Windows started using symlinks whenever the filesystem allowed them. A symlinked python.exe cannot locate the DLLs of some interpreters, most visibly conda, which fails with "DLL load failed while importing _ssl". Every earlier release used copies in practice, and copies are the venv CLI default on Windows, so hardcode that instead of probing. Fixes pypa#1175 Assisted-by: ClaudeCode:claude-fable-5-1
henryiii
force-pushed
the
henryiii/fix/win-symlinks
branch
from
September 3, 2026 14:17
9969afc to
83cdd96
Compare
henryiii
marked this pull request as ready for review
September 3, 2026 14:20
Contributor
Author
|
It looks like we've already started merging 2.0 things, but this should be a 1.6.1 patch. |
layday
approved these changes
Sep 3, 2026
Member
|
I don't know how the whole release process we got set up now is gonna work off another branch if we were to cherry-pick this change from an earlier commit. |
This was referenced Sep 4, 2026
Contributor
Author
|
I'm sure it won't work the first 7 times, but we'll get there. :) I'm going to make a v1 branch and try to set it up with cherry-picks shortly after this goes in. |
henryiii
added a commit
that referenced
this pull request
Sep 9, 2026
The broken probe fixed in #1118 (1.6.0, broken previously) wasn't actually supposed to be there; `python -m venv` doesn't check for symlink support. Even if symlinks are supported, python don't always work symlinked on Windows. This PR removes the check. Fixes #1175. :robot: _AI text below_ :robot: Version 1.6.0 fixed the symlink probe in #1118. Before that fix the probe always failed on Windows, so every isolated environment was built from copies. After the fix, GitHub Windows runners report symlink support, and `venv` started to symlink `python.exe`. A symlinked interpreter cannot find the DLLs of some Python builds, most visibly conda, and pip fails with `DLL load failed while importing _ssl` / `_ctypes`. Projects such as xgboost, LightGBM, and partcad have pinned `build<1.6` to work around this. This change removes the probe and hardcodes `symlinks=os.name != 'nt'`, which is the `venv` CLI default and the behavior all releases before 1.6.0 had in practice. The two tests for the probe are removed with it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The broken probe fixed in #1118 (1.6.0, broken previously) wasn't actually supposed to be there;
python -m venvdoesn't check for symlink support. Even if symlinks are supported, python don't always work symlinked on Windows. This PR removes the check.Fixes #1175.
🤖 AI text below 🤖
Version 1.6.0 fixed the symlink probe in #1118. Before that fix the probe always failed on Windows, so every isolated environment was built from copies. After the fix, GitHub Windows runners report symlink support, and
venvstarted to symlinkpython.exe. A symlinked interpreter cannot find the DLLs of some Python builds, most visibly conda, and pip fails withDLL load failed while importing _ssl/_ctypes. Projects such as xgboost, LightGBM, and partcad have pinnedbuild<1.6to work around this.This change removes the probe and hardcodes
symlinks=os.name != 'nt', which is thevenvCLI default and the behavior all releases before 1.6.0 had in practice. The two tests for the probe are removed with it.