Skip to content

Resolve python3 in the installers instead of bare python - #3

Open
stealthdigital wants to merge 1 commit into
AgriciDaniel:mainfrom
stealthdigital:fix/installer-bare-python
Open

Resolve python3 in the installers instead of bare python#3
stealthdigital wants to merge 1 commit into
AgriciDaniel:mainfrom
stealthdigital:fix/installer-bare-python

Conversation

@stealthdigital

Copy link
Copy Markdown

The bug

install.sh:80 and uninstall.sh:48 invoke bare python for the Gemini loader edit. macOS has shipped no python since Monterey removed the Python 2 stub, so on a stock Mac:

$ ./install.sh --target all
Anti-Slop Brain installed to ~/.codex/skills/anti-slop-brain
Anti-Slop Brain installed to ~/.claude/skills/anti-slop-brain
Anti-Slop Brain installed to ~/.agents/skills/anti-slop-brain
Anti-Slop Brain installed to ~/.openclaw/skills/anti-slop-brain
Anti-Slop Brain installed to ~/.agent-skills/anti-slop-brain
install.sh: line 80: python: command not found
$ echo $?
127

Five skill trees are already on disk at that point, so the failure is a half install rather than a clean abort. uninstall.sh fails at the same step and leaves the anti-slop-brain-install block stranded inside GEMINI.md.

I hit this running tests/test_pipeline.py after a fresh clone, which is where it surfaces as AssertionError: command failed: bash install.sh --target all.

The fix

Both scripts resolve an interpreter through a small resolve_python helper: python3 first, then python only when it reports major version 3. Resolution is lazy rather than at startup, so --help still works on a machine with no interpreter at all, and a machine with none gets a named error instead of command not found.

Why CI is green on a broken installer

actions/setup-python puts a python on PATH, and so does any active virtualenv, so the existing ambient-PATH run in main passes on the runner and on most developer machines. Per CONTRIBUTING, the added test fails before the fix and passes after: it builds a sanitized PATH carrying python3 and the utilities the scripts shell out to, with no python under any name, then round-trips install and uninstall through it.

Reverting only the two shell files, with the test kept:

install.sh: line 80: python: command not found
FAILED as expected: command failed: .../bin/bash install.sh --target gemini

Verification

Run on macOS 15.5, stock PATH, no shim, Python 3.12.

Command Result
python3 tests/test_scanners.py 107 checks passed
python3 tests/test_adapters.py 207 checks passed
python3 tests/test_pipeline.py passed
python3 -m compileall -q scripts tests clean
python3 scripts/lint_voice.py on the three changed files no findings
install.sh --target all then uninstall.sh --target all clean round trip, loader written and removed

No em dash, no en dash, no spaced double hyphen, no local absolute paths in the diff.

Out of scope, flagged rather than fixed

Bare python also appears in AGENTS.md, CLAUDE.md, README.md, SKILL.md, RELEASE_CHECKLIST.md and both ci.yml files. The workflows are fine, since the runner provides python, and the docs are copy-paste papercuts rather than runtime failures. Happy to sweep them in a separate PR if you want the docs consistent with CONTRIBUTING, which already uses python3 throughout.

Also noted while testing: scan_packages.py uses sys.stdlib_module_names, which needs Python 3.10 or newer. On macOS system Python 3.9 it raises AttributeError. That is a separate issue and I have not touched it.

🤖 Generated with Claude Code

install.sh and uninstall.sh invoked bare `python` for the Gemini loader
edit. macOS has shipped no `python` since Monterey removed the Python 2
stub, so `./install.sh --target all` exited 127 after copying five skill
trees, leaving a half-installed surface and no loader. uninstall.sh
failed at the same point and stranded the loader block in GEMINI.md.

Both scripts now resolve an interpreter lazily, preferring python3 and
falling back to python only when it is Python 3, so --help still works
where no interpreter exists at all.

CI could not catch this: actions/setup-python puts a `python` on PATH,
as does any active virtualenv. The added regression test builds a
sanitized PATH carrying python3 and the utilities the scripts call, with
no `python` under any name, and round-trips install and uninstall
through it. It fails with "line 80: python: command not found" against
the unpatched scripts.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.

1 participant