👍

Now that cargo supports external installable sub-commands, does this make more sense to add via that mechanism, rather than being built-in?

That said, given that cargo search presumably already does most of this, maybe it just needs to get some new flags to print more info?

@felixc yeah I'd be in favor of seeing this bake externally first

I gave this a shot: https://github.com/g-k/cargo-show. I'm curious about how people might use it and how to improve it for them.

For example, I'd like to cache package GET requests like crates.io, but I'm not sure if it'd be better to use a sub command specific cache like ~/.cargo-show/ or a shared cache that other sub commands could use like ~/.cargo/cache/package-details/.

@tomjakubowski Is it still desirable today considering the possibility of simply using the linked tool?

There is also https://crates.io/crates/cargo-info which has stalled out.

A thought I had on this command is that it cargo info <dep> would choose the latest version of <dep> in the associated Cargo.lock file and show that. If the user specifies cargo info <dep>@<ver>, ver would act like cargo install and would be a = version requirement.

We could also show either cargo tree -i <dep> or tell the user about the command. Similarly, cargo search could suggest cargo info

We could also show feature activation, either baesd on if <dep> is a direct dependency of the relevant manifest (showing a view like cargo add) or based on resolving the dependency graph (behaving more like cargo tree).

Some prior art

• https://python-poetry.org/docs/cli/#show
• https://yarnpkg.com/cli/info
• https://bundler.io/v2.2/man/bundle-info.1.html
• https://github.com/luarocks/luarocks/wiki/show
• https://lib.haxe.org/documentation/using-haxelib/#info
• https://docs.racket-lang.org/pkg/cmdline.html#(part._raco-pkg-show)

Looks like #6666 is covered by existing commands but could still be useful to either highlight those commands or to include their output

The previously linked package cargo-info provides the requested functionality (thanks, @epage).

In my opinion, info or show command (or a new search flag for that matter) is a good candidate to become a built-in solution. First of all, it exposes useful -- sometimes even necessary -- information on packages, improving search experience and discoverability of packages. It is also quite an expected command for a package manager, so its absence may be felt as a significant lack.
(f.i., I've spent a lot of time trying to find out which cargo command outputs package's info before finding this thread.)

Hi folks, we developed 'cargo-information' as a solution for this issue. You can try it out now.

You can try it through cargo install cargo-information or cargo install cargo-information --git https://github.com/hi-rustin/cargo-information.git.

Features:

• Works with all registries that are compatible with Cargo
• Fetches and displays basic package information (name, version, owners, etc.)
• Shows package dependencies and their versions
• Provides information about package features

If you have any questions, please feel free to open an issue and discuss it with us. Additionally, we are currently having several design discussions ongoing. We would appreciate your valuable input and insights.

How does this work with other registries? I'm assuming with have to extend the standard web API for this or does this use another mechanism than API queries?

How does this work with other registries? I'm assuming with have to extend the standard web API for this or does this use another mechanism than API queries?

It uses the standard download API to download it into the cargo cache dir. Then we can inspect from the local mainfist.

Would adding a web API endpoint for a crate detail lookup functionality be an option? Could save cargo the download unzip and make the data accessible for other programs too.

Would adding a web API endpoint for a crate detail lookup functionality be an option? Could save cargo the download unzip and make the data accessible for other programs too.

If you require to get metadata from crates.io, I think in crates.io we already have this API, but it has a very strict API rate limitation (1 request / second).

The challenge here is it's very difficult to ask all the registries to implement this new API. And for Cargo, we can always download it and parse the manifest. So it seems like there isn't much enthusiasm to add that API to the registry specification.

If the concern is with a lot of extra .crate files, the upcoming GC should help

A thought I had on this command is that it cargo info would choose the latest version of in the associated Cargo.lock file and show that.

Really want this feature.

Now that querying a dependent version requires a manual search to the lock file, I'm not sure if there's a better way. It would be nice to be able to use a command to actualize each of the dependent versions in the lock file