Wrong dependency version when requirements are set in multiple places

[splix]

Problem

I found a strange behavior of the Cargo that looks like a bug. In my case I have a library defined as a dependency in multiple places with different version criteria. All of them may conclude to just one version that fits all criteria, but Cargo decided to use two versions of the same lib and it introduces a compilation conflict.

Here is my setup, look at the bitcoin version:

Lib main have:

[dependencies]
bitcoin = ">= 0.27, < 0.28"
hdpath = { version = "~0.6", features = ["with-bitcoin"] }
emerald-hwkey = "~0.2"

where hdpath is:

[dependencies]
bitcoin = { version = ">= 0.27", optional = true } 

and emerald-hwkey is:

[dependencies]
hdpath = ">= 0.6"
bitcoin = ">= 0.25, < 0.28"

So as a result we have the following criteria for bitcoin lib:

bitcoin = ">= 0.27, < 0.28"
bitcoin = ">= 0.27"
bitcoin = ">= 0.25, < 0.28"

So a version like 0.27.1 should work.

But in practice I see that Cargo decides to use the latest version 0.28.1 for hdpath and 0.27.1 for others. So the project cannot compile because of two different versions of the same lib.

I.e., if I check cargo tree I see:

├── bitcoin v0.27.1
.
├── emerald-hwkey v0.2.0
│   ├── bitcoin v0.27.1 (*)
│   ├── hdpath v0.6.1
│   │   ├── bitcoin v0.28.1

It's unclear why Cargo decides to upgrade here, it doesn't make much sense

Steps

No response

Possible Solution(s)

No response

Notes

It's also discussed here: https://stackoverflow.com/questions/72523805/cargo-publish-uses-different-dependency-version and reported in emeraldpay/hdpath-rs#2

Version

cargo 1.61.0 (a028ae42f 2022-04-29)
release: 1.61.0
commit-hash: a028ae42fc1376571de836be702e840ca8e060c2
commit-date: 2022-04-29
host: x86_64-apple-darwin
libgit2: 1.4.2 (sys:0.14.2 vendored)
libcurl: 7.79.1 (sys:0.4.51+curl-7.80.0 system ssl:(SecureTransport) LibreSSL/3.3.5)
os: Mac OS 12.3.1 [64-bit]

[ehuss]

Thanks for the report! Cargo's resolver tries to pick the newest version, even if that results in duplicates. Ideally it might try harder to prevent that from happening. I suggest sticking with caret requirements as much as possible, although I realize that may be difficult or impossible.

Closing as a duplicate of #9029, and of the work on public/private dependencies (#6129), and future resolver work (#5284).