Cargo update recommends command to "to see how you depend on a package" that does not always work

[Craig-Macomber]

Problem

Running cargo update recommends passing --verbose to see what packages were not updated. When this is done, it includes:

note: to see how you depend on a package, run cargo tree --invert --package <dep>@<ver>

Running this command as recommended to not work in call cases.

Steps

1. Find or create a workspace which when a non-defualt features is enabled depends on an exact package which has a newer version available. cargo is an example of such a repository (current master 0499e31 used to test this).
2. Run cargo update --verbose
3. Use the recommended command from its output to try and find out why a given dependency is depended on:

cargo$ cargo update --verbose
    Updating crates.io index
     Locking 0 packages to latest compatible versions
   Unchanged openssl v0.10.57 (available: v0.10.68)
   Unchanged thiserror v1.0.69 (available: v2.0.9)
note: to see how you depend on a package, run `cargo tree --invert --package <dep>@<ver>`
cargo$ cargo tree --invert --package [email protected]
error: package ID specification `[email protected]` did not match any packages

        Did you mean `opener`?

Possible Solution(s)

I see four possible fixes:

1. Pass the to --invert instead of using the --project option. Then either:
   a. add --all-features since cargo update applies to all features and thus it may be required for the packages it mentions in its output. A draft showing this solution is in fix: Adjust "to see how you depend on a package" message to use a command format that supports flags like --all-features #14991
   b. cargo tree --inverse able to look up packages that are under a feature without the --all-features flag (maybe report in the output which edges are conditional on a feature)
2. Make --all-features (and similar options) work with --inverse when providing the via --project, and add --all-features to the recommended command
3. Make the command as currently recommended actually work. Maybe annotate dependency edges in the output which are feature conditional. Maybe also fix feature related flags so they work if added.

Notes

There are two ways to pass the package you want to investigate to cargo tree --inverse. It can be passed to the --inverse option, or to the --package option. Using the --package approach (as currently done) doesn't work with flags like --all-features:

cargo$ cargo tree --invert --package [email protected] --all-features
error: cannot specify features for packages outside of workspace

This seems like a bug to me. If using invert and not providing its optional , the the --all-features argument should probably be applied to the workspace and not the package. I would expect either --invert's to be required (and not allow using --package instead) OR for using --package instead to work the same.

Personally I find --invert making the SPEC optional and allowing package to work instead to be confusing when using workspaces and features, but its an existing feature so we should probably keep it.

I also find it a bit surprising that when searching for a package that actually exists in the lock file and in the crate registry, the error says:

error: package ID specification [email protected] did not match any packages

    Did you mean `opener`?

I think an error more like:

error: package ID specification [email protected] exists in this workspace but is not found with this configuration.

    Consider adding `--all-features`

Would make sense in this case, and if not offline, for the case where its actually missing locally:

error: package ID specification [email protected] exists in the crate registry (maybe link it here) but is not currently in use.

    Did you mean `opener`?

There is also related code which may be impacted by this issue in

cargo/src/cargo/ops/registry/info/view.rs

Lines 402 to 406 in 9b5efd9

	shell.note(format_args!(
	"to see how you depend on {name}, run `{literal}cargo tree --invert --package {name}@{version}{literal:#}`",
	name = package_id.name(),
	version = package_id.version(),
	))

Version

cargo 1.83.0 (5ffbef321 2024-10-29)

[epage]

This seems like a bug to me. If using invert and not providing its optional , the the --all-features argument should probably be applied to the workspace and not the package. I would expect either --invert's to be required (and not allow using --package instead) OR for using --package instead to work the same.

I agree that we should probably pass it to --invert.

I think an error more like:

error: package ID specification [email protected] exists in this workspace but is not found with this configuration.

    Consider adding `--all-features`

This was the solution alternative I was thinking of when commenting on #14991.

The message was added in b05dc26 as part of #13372. The suggestion dates back to Rustin170506/cargo-information#2. Hmm, looking through the various PRs, I'm not finding the conversation around this but I feel like we had one about not wanting the command to be too complicated (it could also need --all-targets).

If we find a way to suggest --all-features or --all-targets as appropriate, we help all cargo tree users, even if the road is a bit bumpier for people coming from cargo info and cargo tree.

[weihanglo]

(it could also need --all-targets).

--target=all these days btw.