Probe the Interpreter the Way the Host Contract Declares It - #647
Merged
Conversation
The hook named python3. docs/host-setup.md states that a native Windows install registers py and python but not python3, that the name resolves to a Microsoft Store alias stub, and that Git Bash inherits the Windows PATH, so the hook could not run for a Windows contributor. spec/host-tools.json already encodes the answer as its probe order, and the hook now follows the same order rather than restating a name the contract says is wrong. Checked on a PATH carrying py and no python3, with a stand-in for the Windows launcher. The hook passes there, and the previous version on the same PATH exits 127 with "python3: not found", so this fixes a real break rather than hardening against a hypothetical one. With neither interpreter present it prints what did not run and points at the contract, and exits 1, since a hook that cannot run its gates must not report a clean commit. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Updates the repo’s local pre-commit hook to select a Python interpreter in the platform-aware order declared by the host contract, so the hook remains usable on native Windows setups where python3 may be absent.
Changes:
- Adds interpreter selection logic to prefer
python3and fall back topy -3when needed. - Routes the prose and EOL checks through the selected interpreter.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
The previous commit tested `command -v python3` and did not fix the case it was written for. The Microsoft Store alias stub is on PATH and fails only when run, which docs/host-setup.md states in the same paragraph the fix cited, so a presence test selects the stub on exactly the host the change was meant to serve. The hook now runs the probes spec/host-tools.json declares, python3 --version then py -3 --version, which is what tells a working interpreter from a name. The chosen one is wrapped in run_py() rather than held in a variable, so nothing depends on intentional word splitting of "py -3". Checked against a stand-in for the stub, present on PATH and exiting non-zero: presence version (0a26cd2) selects the stub and fails probe version skips it, uses py -3, exits 0 And against the other half of the finding, a py that exists and rejects -3: both probes fail, the hook names what did not run, points at the contract and exits 1 rather than falling through to a name that does not work. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.
Answers the suppressed finding on the promotion pull request #643, which cannot take a fix of its own since its head is
develop.Accepted. This is the repository contradicting itself:
docs/host-setup.mdstates the hazard in its own paragraph, andspec/host-tools.jsonalready encodes the answer as its probe order,[["python3", "--version"], ["py", "-3", "--version"]]. The hook restated a name the contract says is wrong on one supported platform. It now follows the same order rather than naming an interpreter.Checked on a PATH that has
pyand nopython3Rather than reasoning about Windows from Linux, the shape was reproduced: a PATH carrying
git,shand a stand-in for the Windows launcher, and nopython3at all.The previous version on that same PATH:
So this fixes a real break rather than hardening against a hypothetical one. Worth being precise about the failure it was: exit 127 is non-zero, so the old hook blocked the commit rather than passing it falsely. The defect is that it was unusable on such a host, not that it was silently wrong.
With neither interpreter present
It names what did not run and points at the contract, and exits non-zero. A hook that cannot run its gates must not report a clean commit, which is the same rule
prose_lint.pyfollows when it announces a dropped rule rather than going quiet.Verification
552 tests pass,
prose_lint.pywith the CI check list exits 0, andrepo_gate.pyreportseol,eol-coverageandsha-pinclean. The hook ran on this commit.🤖 Generated with Claude Code