install: wire a tool's pit aliases into installing it - #432
Merged
Conversation
Follow-up to the previous commit, which made this its own verb. Wrong call: a set of commands behind one dispatcher is not usable from the pit until the words that reach them exist, so wiring them up is part of installing the tool, not a second thing to remember afterwards. /install <tool>, /tools install <tool>, and `moshcode install <tool>` now adopt whatever aliases the tool proposes, and /upgrade does the same — an upgrade is where a tool gains commands, so a roster adopted once at install time goes stale the first time it ships something new. That is exactly how cli-tools' own generate-names never reached anybody. Quiet by construction, which is what makes it safe to hang off an install: a tool that offers nothing (every engine, most tools) prints nothing, and one that cannot be asked is silent rather than following a successful install with an error about a nicety. Names you bound yourself are still never overwritten. /alias install <tool> stays, for tools installed before this existed. /tools install <name> now routes to the installer instead of answering `unknown tool "install"` — it is the obvious spelling after /tools has just printed the roster. Two test fixes this surfaced, both real: test/tools.test.mjs used a fake shell as a spy that a tool's own shebang could overwrite, and its runner never isolated $HOME — so a successful install in the suite could write the aliases of whoever ran it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ThreatCrush Security Scan3 finding(s) in the 8 file(s) this pull request changes. MEDIUM: 3
52 pre-existing finding(s) elsewhere in the repository — **HIGH/CRITICAL**: 5 | **MEDIUM**: 41 | **LOW**: 6Not introduced by this pull request. The full set is in the Security tab.
…and 32 more. Full results in the Security tab. Snippets are redacted; ThreatCrush never prints matched credential material. |
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
1 participant
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.
Follow-up to #431, which landed the mechanism as its own verb. That was the wrong shape: a set of commands behind one dispatcher is not usable from the pit until the words that reach them exist, so wiring them up belongs to installing the tool — not to a second thing you have to remember afterwards.
What changes
/install <tool>,/tools install <tool>andmoshcode install <tool>adopt whatever aliases the tool proposes./upgradedoes the same. An upgrade is where a tool gains commands, so a roster adopted once at install time goes stale the first time it ships something new — which is exactly how cli-tools' owngenerate-namesnever reached anybody's prompt./tools install <name>now routes to the installer instead of answeringunknown tool "install". It is the obvious spelling right after/toolshas printed the roster./alias install <tool> | --allfrom install: wire a tool's pit aliases into installing it #431 stays, for tools installed before this existed.Why it is safe to hang off an install
Quiet by construction. A tool that offers nothing — every engine, most tools — prints nothing and spawns nothing. A tool that cannot be asked stays silent rather than following a successful install with an error about a nicety. Names you bound yourself are still never overwritten, and the merge is capped and validated exactly as in #431.
Test fixes this surfaced
Both pre-existing in
test/tools.test.mjs, both real:$HOME. Now that a successful install may write~/.moshcode/aliases.json, the suite could edit the aliases of whoever ran it.Full suite green: 2324 tests, 0 fail.
🤖 Generated with Claude Code