axum pins itoa to 1.0.5 causing issues with cargo update
#1814
Comments
Merged
bors
added a commit
to rust-lang/cargo
that referenced
this issue
Mar 14, 2023
Accurately show status when downgrading dependencies ### What does this PR try to resolve? A few times now I've ran into issues where Cargo ends up downgrading a dependency in order to satisfy a pinned dependency somewhere in the dependency graph. Unfortunately this is not clear in the output of `cargo update`, which just shows all the changed dependencies as `Updating`. References: * #5702 * [Finding a pinned dependency edge](https://users.rust-lang.org/t/finding-a-pinned-dependency-edge/81157) * tokio-rs/axum#1814 ### How should we test and review this PR? This is a small change that tries to make dependency downgrades stand out more in the output of `cargo update`. I have not added any new tests since the existing tests seem to cover this functionality. Some tests still fail, these refer to Git dependencies. I'm honestly not sure how to handle these, so I'd like to get some feedback on this before I fix those tests up. Git commits form a DAG, so one option is to see if the new commit is an ancestor of the old one (mark as "updating"), if the old commit is an ancestor of the new one (mark as "downgrading"), or neither (could be from parallel branches) we could compare based on timestamp in that case. ### To do * Fix up tests for Git dependency updates
bors
added a commit
to rust-lang/cargo
that referenced
this issue
Mar 14, 2023
Accurately show status when downgrading dependencies ### What does this PR try to resolve? A few times now I've ran into issues where Cargo ends up downgrading a dependency in order to satisfy a pinned dependency somewhere in the dependency graph. Unfortunately this is not clear in the output of `cargo update`, which just shows all the changed dependencies as `Updating`. References: * #5702 * [Finding a pinned dependency edge](https://users.rust-lang.org/t/finding-a-pinned-dependency-edge/81157) * tokio-rs/axum#1814 ### How should we test and review this PR? This is a small change that tries to make dependency downgrades stand out more in the output of `cargo update`. I have not added any new tests since the existing tests seem to cover this functionality. Some tests still fail, these refer to Git dependencies. I'm honestly not sure how to handle these, so I'd like to get some feedback on this before I fix those tests up. Git commits form a DAG, so one option is to see if the new commit is an ancestor of the old one (mark as "updating"), if the old commit is an ancestor of the new one (mark as "downgrading"), or neither (could be from parallel branches) we could compare based on timestamp in that case. ### To do * Fix up tests for Git dependency updates
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug Report
Version
axum v0.6.10
Platform
Linux
Description
cargo updateon my project picks axumv0.6.7which confused me. If I ask explicitly for the latestcargo update -p axum --precise 0.6.10it downgrades itoa1.0.6->1.0.5. It's pinned to the latter in the axum manifest, which is presumably the reason for the funky default selection.I don't see any benefit or mention of pinning in the pr that made this change. The pr is also older than itoa
1.0.6so can't have been avoiding it. Perhaps this was simply a mistake?The text was updated successfully, but these errors were encountered: