Open timonbimon opened 4 months ago
This is working as expected—1.25.0
and 1.29.1
are considered compatible version requirements since cargo
will unify them to 1.29.1
. That's because 1.25.0
is actually a short-hand for ^1.25.0
. tokio
was already "unified" in your workspace.
It'd be a bug if you had =1.29.1
in that crate and auto-inherit had replaced it with 1.25.0
.
Does that make sense?
sorry, maybe I didn't phrase it very well (also apologize for misspelling Luka for Luca in the other issue, it's the Luke in LukeMathWalker that got me 😉)
in the workspace Cargo.toml we had
tokio = "1.25.0"
and in the crate/Cargo.toml I had the following diff after running cargo autoinherit
- tokio = "1.29.1"
+ tokio = { workspace = true }
so the more specific, higher version in the crate got lost (now it would just point towards the ^1.25.0
in the workspace)
I had indeed misunderstood the issue. That's a bug, we should indeed use the highest version as the base.
My specific example: we already had
tokio
in our workspace with version1.25.0
.Autoinherit replaced set
tokio
toworkspace = true
in one of our crates, that had tokio at version1.29.1
instead of the workspace version.so in a way cargo autoinherit helped point us towards exactly the problem it's trying to solve ("If you mess it up, you end up with different versions of the same dependency within your workspace"), but it did so somewhat silently (I was just running through the changes across 50 files manually and happened to see it) and it would be awesome if it threw a big warning saying that the two versions differ!