Display latest version compatible with input spec

[PaulDance]

Dear maintainer,

Whenever using cargo info <pkg>@<spec> where <spec> does not select the latest version, the command displays the latest version available on the used registry. This is a fine feature that should be kept, but in addition, it would be nice if it could also display the latest available version that matches the given spec. This would enable me to easily detect whether a currently-installed package is in the latest version available that matches a configured spec or not, to then know whether it needs an update or not.

For example, if <pkg> has 0.1.0, 0.1.1 and 0.2.0 available, then cargo info <pkg>@0.1 should display version: 0.1.0 (latest compatible 0.1.1) (latest 0.2.0) or even just version: 0.1.1 (latest 0.2.0), but that might too drastic of a change -- I'll let you judge on that.

From what I can see in src/ops/info.rs and src/ops/view.rs, all versions of a package are retrieved from the registry and then filtered offline to only keep the ones compatible, so adding this should not be too big of a change, right?

Cheers,
Paul.

[epage]

Crates.io tends to highlight the latest version in every major version: https://crates.io/crates/clap/versions

This is an interesting idea to do something similar here. My main concern is bloat in the output. I mentioned in another issue the idea of putting some information behind --verbose. This might be a possibility.

Note that MSRV compatibility is another dimension.

Also, I am looking at trying to communicate some of this information in cargo update for direct dependencies so that a dry-run would be kind of like cargo outdated and could help advise you on situations like this. Personally, I think this is more of where we should focus this interaction since that is the tool users will be using for dealing with versions.

[PaulDance]

My main concern is bloat in the output. I mentioned in another issue the idea of putting some information behind --verbose. This might be a possibility.

That's a possibility indeed, although the output bloat wouldn't be that high I think.

Note that MSRV compatibility is another dimension.

Yes, you're right, there should be a MSRV filtering similar to what is already done.

Personally, I think this is more of where we should focus this interaction since that is the tool users will be using for dealing with versions.

True, libraries are more important in this aspect. However, I'm specifically considering only binary packages here, for example installed through cargo install, so things that would be unrelated to any kind of current workspace.

[epage]

For some reason, I missed that this suggested we pick the highest within a spec. That was implemented in #53.

e.g. try

$ cargo info clap@3
clap #argument #cli #arg #parser #parse
A simple to use, efficient, and full-featured Command Line Argument Parser
version: 3.2.25 (latest 4.5.3)
...

[PaulDance]

Oh, right, thanks! Maybe it had not been in a release yet when I tested my things 🤔

If this is indeed what I initially meant, then the current issue can be closed.