missing cargo command suggestions

[joshtriplett]

Inspired by the various cargo subcommands available in the broader crates.io ecosystem: we should consider adding a mechanism to automatically search for Cargo subcommands if someone enters an unknown subcommand. For instance, cargo tree could suggest installing cargo-tree. This could make use of metadata provided by crates.io.

cc @carols10cents

[withoutboats]

Two UX thoughts:

• Probably this pulls info from the index; it should not ever update the index though (a user who accidentally writes cargo biuld should never then sit waiting for the index to update to look for cargo-biuld).
• Some subcommands are installed through crates with different names (e.g. the "correct" implementation of cargo add is in cargo-edit, not cargo-add). Its unclear how we would support discovery in these cases.

[joshtriplett]

For the latter, I'd suggest that we have metadata that a crate can provide to indicate that it ships a specific cargo command, and cargo should show all crates that provide the specified command, ideally in an order comparable to the crates.io search results.

[epage]

In #11226, it was brought up that we have access to "the full list of crates" but @weihanglo pointed out

Mind that the precondition might not be fulfilled when the sparse-registry becomes the default in the future, unless we address it with a solution like #10928.

And I followed up with

Until we have a full list of crates, we could potentially check the registry specifically for cargo-foo but

• We would want to do this offline as it would be surprising to reach out over the network

• Sparse registry only caches locally what you use which would make offline checking for cargo-foo very limited

[epage]

I think there can be value in doing this without it being perfect. To one extreme, I brought up in #11226

Would it be worthwhile to always add a suggestion To install the command, run 'cargo install cargo-foo' until we can show it only when needed?

I lean towards "no" but thought it worth bringing up.

and @weihanglo brought up

If Cargo found a crate with the exact name, but it were a malicious/low-quality/abandoned crate, should Cargo recommend it?

which can apply more generally to this issue.

cargo-add has somewhat similar problems and we have the following issues around supply chain attacks

• Warn about security advisories for cratres being added with cargo add #10654
• Help catch typo squatting when adding dependencies #10655
• Help catch internal-crate squatting attacks when adding a dependency #10656

[estebank]

FWIW, if there are technical reasons that the full registry isn't available (which might be a problem in the future), I think it would be useful to have even a small list of popular installeable plugins. In my case in particular, it was noticing that cargo audit didn't provide a good suggestion. I'm sure there's a small handful of plugins that could be mechanically queried and kept in a list in cargo itself. We could even invoke cargo install cargo-audit if someone executes cargo audit for the first time then, given that we'd have a high confidence (instead of relying on a heuristic).

[simonbuchan]

To be clear, this is more for the use case of ad-hoc plugins like add, not plugins expected as part of the workflow for a crate/workspace, like insta?

For the former, a simple blind suggestion of This may be provided by "cargo install cargo-foo" message added to the error for cargo foo seems like all I would expect (I would be pretty annoyed it if tried to fetch the index for a simple typo, for example), but the latter I would expect more along the lines of Cargo.toml getting something like [plugins] foo = <dependency-spec> - obviously the latter has a bunch of more complex issues to think about (incompatible versions, can you use features, git paths, etc.?)