Yes, that workflow is important. I accidentally made it more broad than intended by not clarifying that I mean within cargo update. Even then, I do leave room open for it. I just don't want to block progress on it here and I want to make my stance sufficiently clear to help guide those future discussions.
1 Like
Just a quick remark. Every time I see the -i option I think it's for “interactive” (like in git), which could be useful in the future if we want to add a mode where the tool tell what it is going to do and ask for confirmation (or even select which dependency to update).
3 Likes
I looked through this again, and (somewhat superficially) it seems to make sense.
But, there is so much complexity and mental overhead. It simply gets difficult to track a large set of dependencies.
I really liked the earlier discussions of a global crates.io version.
Something like cargo update —registry crates.io=20230728.3 to revert everything to a previous snapshot to bisect a regression. And cargo update —registry crates.io —except tokio to keep just tokio pinned, etc.
When one has a lot of git repositories with things like dependabot operating on them, there can just be unnecessary drift in lockfiles due to timing. With a global crates.io version, I have just one number I need to think about in the general/default case.
#5221 is the issue for that. I suspect the main implementation complexity is having some kind of ordered marker that we can filter the packages by.
Apparently this made it into a proposal in the Cargo repo:
1 Like
This topic was automatically closed 540 days after the last reply. New replies are no longer allowed.