Description
IntegrationBase.resolve_python_interpreter in src/specify_cli/integrations/base.py selects python3/python by existence on PATH (shutil.which). On a stock Windows machine python3 resolves to the Microsoft Store App Execution Alias stub: it exists on PATH, prints an installer hint, and exits non-zero. The resolver returns "python3" anyway, so every {SCRIPT} invocation generated for the py script type is broken (Python was not found; run without arguments to install from the Microsoft Store).
This is the CLI sibling of #3304 (assessed valid, severity medium). The sh-script variants of the same existence-vs-runtime defect were fixed in #3312 and #3320; the Python resolver still has it. The irony: sys.executable is guaranteed to work here (the CLI itself runs on it) and the resolver prefers the dead stub over it.
Reproduction
On Windows 11 with Git for Windows and no real Python on PATH (the default WindowsApps\python3.exe stub present):
specify init target --integration cursor --script py --ignore-agent-tools
Generated command files contain python3 .specify/scripts/python/..., which fails at runtime with the Store installer hint. The same machine state is the one documented in #3304.
Expected behavior
The resolver skips interpreters that do not actually run and falls back to sys.executable, which is always live.
Proposed fix
On Windows only, verify the found interpreter with a [path, "-c", ""] run before accepting it, mirroring the parse-success-not-availability approach of #3312/#3320. POSIX keeps the plain existence check (no App Execution Alias there, no extra subprocess). I have a patch with regression tests ready and will open a PR.
Description
IntegrationBase.resolve_python_interpreterinsrc/specify_cli/integrations/base.pyselectspython3/pythonby existence onPATH(shutil.which). On a stock Windows machinepython3resolves to the Microsoft Store App Execution Alias stub: it exists onPATH, prints an installer hint, and exits non-zero. The resolver returns"python3"anyway, so every{SCRIPT}invocation generated for thepyscript type is broken (Python was not found; run without arguments to install from the Microsoft Store).This is the CLI sibling of #3304 (assessed valid, severity medium). The sh-script variants of the same existence-vs-runtime defect were fixed in #3312 and #3320; the Python resolver still has it. The irony:
sys.executableis guaranteed to work here (the CLI itself runs on it) and the resolver prefers the dead stub over it.Reproduction
On Windows 11 with Git for Windows and no real Python on
PATH(the defaultWindowsApps\python3.exestub present):Generated command files contain
python3 .specify/scripts/python/..., which fails at runtime with the Store installer hint. The same machine state is the one documented in #3304.Expected behavior
The resolver skips interpreters that do not actually run and falls back to
sys.executable, which is always live.Proposed fix
On Windows only, verify the found interpreter with a
[path, "-c", ""]run before accepting it, mirroring the parse-success-not-availability approach of #3312/#3320. POSIX keeps the plain existence check (no App Execution Alias there, no extra subprocess). I have a patch with regression tests ready and will open a PR.