-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cargo update should not highlight non-semver-compatible "(latest: v0.23.5)" for indirect dependencies #13908
Comments
@rustbot label +Command-update +A-console-output |
Thanks for the suggestion! Agree it is not actionable locally and quite verbose, especially when you have only few direct dependencies and that's very noisy. However, I see it as an opportunity to encourage user to collaborate with upstreams. Putting in behind One similar work we've done is future-compatible warnings. Cargo indeed puts them behind |
This seems like bad reasoning, since
I suppose that the If anything, I would be happy if you showed Unchanged semver-incompatible bumps for my workspace's direct dependencies, but it currently doesn't -- so that also feels inconsistent. To summarize:
(I happen to do a lot of this, trying to push the ecosystem forward -- but I think I'm in a small minority, and anyway it's still a different level of actionable/effort to effect changes like this, so any production user will have to timebox these efforts.) (cc @epage who's done a lot of work in this area.) |
Sorry for the delay, I've been doing some focused time trying to wrap things up before I get to my 100+ github notifications between MSRV, 2024 Edition, and RustNL (wish timing worked to talk to you in person about this). This also caused confusion in #13873 (comment) This was previously discussed in #13372. The idea behind this comes from
I'd have to check the implementation and issues, but I have a feeling this runs counter to the feedback you gave for CC @jonhoo as you mentioned in the release changes stream your excitement for reporting changes and want to make sure we capture multiple perspectives |
I'm curious what feedback you're thinking of exactly! I think giving this |
With
changed dependencies are shown, regardless of the nature of the change ( Why doesn't this make sense when an MSRV isn't set? Cargo is preventing an upgrade and we want the user to know. Right now, resolving some of those upgrades is more manual (edit version requirements, bug dependencies) but we will be adding support for a flag to help with the version requirements. |
IIRC the output in
Yes, I understand what it's doing and why it is the way it is. I'm arguing that whether the "(latest ..)" badge is shown should be independent of whether a dependency is changed (due to a semver-compatible upgrade/downgrade), because whether a semver-compatible update happened since the last time I ran Including the plan for the MSRV-aware resolver, I think there are 3 different categories here:
|
Thanks for CCing me! Yeah, I think I agree with @djc above on the things that are important to highlight. In particular, I agree that dependencies that could not be updated to the latest version for a reason that is under the user's control (i.e., direct dependency or MSRV) should be highlighted independently of whether that dependency happened to be updated in this particular I very much empathize with @weihanglo wanting to encourage upstream contribution, but as @djc points out there is a trade-off here where overloading users with hard-to-action information is likely to lead to worse overall outcomes (people ignoring warnings) rather than the virtuous effects we wish to see. I sadly don't have a great suggestion for how to highlight updates that are blocked indirectly. Personally, I also tend to run |
Problem
I just ran my weekly
cargo update
against the workspace at work, and it highlighted this change:This workspace does not have a direct dependency on rustls. As such, I would suggest this information isn't actionable enough to merit a mention in the non-verbose
cargo update
output (it would definitely fit in with the verbose output).Steps
No response
Possible Solution(s)
No response
Notes
No response
Version
The text was updated successfully, but these errors were encountered: