No warning when workspace version already exists but differs from the one being replaced

[timonbimon]

My specific example: we already had tokio in our workspace with version 1.25.0.

Autoinherit replaced set tokio to workspace = true in one of our crates, that had tokio at version 1.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!

[LukeMathWalker]

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?

[timonbimon]

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)

[LukeMathWalker]

I had indeed misunderstood the issue. That's a bug, we should indeed use the highest version as the base.