fix: Adjust "to see how you depend on a package" message to use a command format that supports flags like --all-features

[Craig-Macomber]

When running cargo update in a workspace, it applies to all packages, including transitive dependencies which are only used when specific non default features are enabled.

This means that when a given package is not updated by cargo update, it might only be included in cargo tree if the specific feature, or --all-features is specified.

cargo update suggests the command cargo tree --invert --package <dep>@<ver> to see now the noted packages are depended on, but this fails to find packages if they are only included with a specific feature.

Additionally, adding --all-features to this command as is fails with the message:

error: cannot specify features for packages outside of workspace

This PR changes the the suggested command so that it should work for all packages which cargo update might suggest using it with.

I am aware that creating this PR is not exactly following the process outlined in https://doc.crates.io/contrib/process/index.html : since this is a minor change that is easier to just show in a diff I figured a PR would be simpler to evaluate than an issue. If it would be better to file an issue for this and only create the PR if/when it gets marked as "S-accepted", let me know, and I'll close the PR for now and file an issue.

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @epage (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[epage]

I am aware that creating this PR is not exactly following the process outlined in https://doc.crates.io/contrib/process/index.html : since this is a minor change that is easier to just show in a diff I figured a PR would be simpler to evaluate than an issue. If it would be better to file an issue for this and only create the PR if/when it gets marked as "S-accepted", let me know, and I'll close the PR for now and file an issue.

I tend to find people under-estimate what might need an issue. I tend to put "doesn't need an issue" at a typo level. This might seem like a trivial change but we were fairly intentional with what text we put in cargo info which cargo update copied. There are other potential solutions that could be worth discussing and weighing out.

Part of the reason for emphasizing Issues is they are a much better place to seek agreement on the problem and solution before reviewing code. Doing that in this PR could fragment the conversation because PRs are a lot more likely to come and go. Sometimes, its because authors move on. Sometimes its because authors choose to create multiple PRs.

[Craig-Macomber]

I am aware that creating this PR is not exactly following the process outlined in https://doc.crates.io/contrib/process/index.html : since this is a minor change that is easier to just show in a diff I figured a PR would be simpler to evaluate than an issue. If it would be better to file an issue for this and only create the PR if/when it gets marked as "S-accepted", let me know, and I'll close the PR for now and file an issue.

I tend to find people under-estimate what might need an issue. I tend to put "doesn't need an issue" at a typo level. This might seem like a trivial change but we were fairly intentional with what text we put in cargo info which cargo update copied. There are other potential solutions that could be worth discussing and weighing out.

Part of the reason for emphasizing Issues is they are a much better place to seek agreement on the problem and solution before reviewing code. Doing that in this PR could fragment the conversation because PRs are a lot more likely to come and go. Sometimes, its because authors move on. Sometimes its because authors choose to create multiple PRs.

I understand that argument for creating an issue.

Since you didn't give an explicit answer and I don't want to make assumptions: what action would you prefer I take here? Would you like me to I create an issue and mark this PR as draft (or close it?)?

[epage]

Sorry I wasn't more clear, yes, please open an issue about the user-facing problem.

[Craig-Macomber]

Sorry I wasn't more clear, yes, please open an issue about the user-facing problem.

I have filed #14993 and attempted to better acknowledge alternative possible solutions. Thank you for your guidance.