Repository navigation
docs: correct what the not-found handler can install - #11830
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Central YAML (base), Organization UI (inherited) Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 WalkthroughWalkthroughThe documentation updates describe registry-based command resolution for command-not-found auto-installation. They document configured-tool requirements, raw backend limitations, configuration scope, shim support, and alternative commands. ChangesCommand-not-found documentation
Estimated code review effort: 1 (Trivial) | ~5 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/troubleshooting.md`:
- Line 393: Update the fallback phrase in the troubleshooting documentation from
“Falling that” to “Failing that,” leaving the rest of the sentence unchanged.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Central YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro Plus
Run ID: 4068be10-6b30-4670-8fb0-740e57879d91
📒 Files selected for processing (3)
docs/dev-tools/index.mddocs/troubleshooting.mdsettings.toml
Greptile SummaryThe PR corrects documentation for command-not-found auto-install behavior and clarifies that registry binary metadata enables first-use installation.
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains. Important Files Changed
Reviews (2): Last reviewed commit: "docs: correct what the not-found handler..." | Re-trigger Greptile |
The registry gained `bins` metadata in jdx#11666 and #11675-jdx#11678, and `install_missing_bin` consults it before falling back to executable discovery from installed versions. A tool that is configured but has never been installed is therefore resolved and installed on first use, including when the binary name differs from the registry short name (`rg` for `ripgrep`). Three places still describe the old behaviour, and send readers to a workaround -- install one version by hand first -- that is no longer needed. The real limitation is narrower: a tool configured by a raw backend spec carries no bin metadata, so a command name cannot be traced back to it. Installing it explicitly is the answer there, since `mise install` and `mise x` materialise the whole configured toolset whatever the backend. Also drop "if the terminal is interactive" from the shim sentence. The shim path has no interactivity check; the only extra gate is offline `usage complete-word` completion.
3fa0612 to
b56c206
Compare
The problem
not_found_auto_installis documented as only able to install a missing version of a tool thatalready has one installed. That stopped being true when the registry gained
binsmetadata in#11666 and #11675–#11678.
Measured on v2026.8.3, from an empty data directory, PATH-based (
eval "$(mise activate bash)"),with neither binary present on the system:
Both were installed on first use, and neither had ever been installed. The second case also rules
out name matching: the binary is
rgwhile the tool isripgrep.Control — a tool with no registry entry, so no
bins:So the limitation still exists, but it is a different one: tools mise's registry does not know,
rather than tools never installed. 914 of 956
registry/*.tomlfiles carrybins.What the code does
install_missing_binfilterslist_missing_versionsthroughREGISTRY.get(short).provides_bin(bin_name)and applies registry override order before fallingback to executable discovery from installed versions — the comment there says so explicitly:
"Registry bin metadata is the only provider signal available before a tool has ever been installed."
src/shims.rsgoes through the same function.The change
Prose only, in the three places that state the old limitation:
settings.toml— thedocsblock fornot_found_auto_installdocs/troubleshooting.md— the section, including its heading. It previously led with aworkaround ("install one version by hand first") that is no longer needed; it is now a short list
of the reasons the handler genuinely does not fire, with
mise x/mise ras the answer for rawbackend specs.
docs/dev-tools/index.md— the Limitation bulletTwo claims in that text were checked rather than assumed:
mise xdoes install a raw backend spec on demand —mise x -- fd --versionwith only"ubi:sharkdp/fd" = "10.2.0"configured printsubi:sharkdp/fd@10.2.0 ✓ installedthenfd 10.2.0.if the terminal is interactiveisdropped from that sentence. With stdin and stdout both piped, a shim for a configured-but-missing
version installs it.
src/shims.rshas no interactivity check; the only extra gate is offlineusage complete-wordcompletion.No render round-trip
The
docs = """…"""field feeds no generated artifact, somise run renderproduces no diff:codegen_settingsinbuild.rsreads onlydescription/env/default/parse_env/deserialize_with;xtasks/render/schema.tsreads onlydescription; anddocs/settings.data.tsrenders
props.docs ?? props.descriptionfromsettings.tomlat VitePress build time.No behaviour changes and no Rust is touched.
Context
Raised while answering #4805, where a user asked whether a
PATH-based setup can install tools on first use. It can — the documentation said otherwise.
Summary by CodeRabbit
mise xormise ras alternatives.