fix(integrations): skip Windows Store python3 alias stub in resolve_python_interpreter#3385
Merged
Merged
Conversation
…ython_interpreter
On stock Windows, python3 on PATH is the Microsoft Store App Execution
Alias stub: it exists but only prints an installer hint and exits
non-zero, so generated {SCRIPT} invocations for the py script type were
broken. Verify the found interpreter actually runs before accepting it,
on Windows only, mirroring the parse-success-not-availability approach
of github#3312/github#3320 for the sh scripts. POSIX keeps the plain existence
check. sys.executable remains the fallback and is always live.
Fixes github#3383
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes Windows-specific interpreter resolution in IntegrationBase.resolve_python_interpreter by avoiding the Microsoft Store “App Execution Alias” python3/python stubs that exist on PATH but fail at runtime, ensuring {SCRIPT} invocations for the py script type remain runnable.
Changes:
- Add a Windows-only runtime probe for
python3/pythoncandidates found viashutil.which, falling through when the candidate cannot execute. - Introduce
_interpreter_runs()helper (subprocess + timeout) to validate candidates on Windows. - Add regression tests covering stub rejection, successful acceptance, fallthrough from
python3→python, and ensuring POSIX does not spawn a probe.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| src/specify_cli/integrations/base.py | Adds Windows-only runtime validation to skip python3/python alias stubs and fall back to sys.executable. |
| tests/integrations/test_base.py | Adds targeted regression tests for Windows stub behavior and confirms POSIX keeps existence-based resolution without subprocess checks. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
…rd I/O Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The tests fake shutil.which with POSIX paths; on Windows CI the real sys.platform made the stub probe run against those fake paths and fall through to sys.executable. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Collaborator
|
Thank you! |
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
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.
Description
Fixes #3383
IntegrationBase.resolve_python_interpreterpickedpython3/pythonby existence onPATH(shutil.which). On stock Windows,python3resolves to the Microsoft Store App Execution Alias stub, which exists but only prints an installer hint and exits non-zero. Every generated{SCRIPT}invocation for thepyscript type was therefore broken on that machine state, while the guaranteed-livesys.executablefallback sat unreached.Root cause: the same existence-vs-runtime defect #3304 documents for the sh scripts (assessed valid, severity medium there); the fixes in #3312 and #3320 covered
common.shbut not this Python resolver.Fix: on Windows only, verify the found interpreter with a
[path, "-c", ""]run before accepting it, and fall through to the next candidate (thensys.executable) when it fails. POSIX has no App Execution Alias, so it keeps the plain existence check and spawns nothing — a regression test asserts that. The run check lives in a small_interpreter_runshelper with a timeout and OSError guard.Testing
uv run specify --helpuv sync && uv run pytest— 3776 passed, 105 skippedFour regression tests in
TestResolvePythonInterpreter: stub rejected →sys.executable, working interpreter accepted, stubpython3falling through to a workingpython, and POSIX never spawning the run check. The first three fail onmain.AI Disclosure
Bug found, patch and tests written with GitHub Copilot CLI; reproduction and full test suite run and verified locally by me. I do not have a Windows machine in this environment; the Windows behavior is covered by the monkeypatched tests and matches the machine state documented in #3304.