Description
Problem
When using cargo add, the version chosen for the new dependency appears to always be the latest one from crates.io, even if another package the workspace already has that package at a different version.
Steps
Steps
# a/Cargo.toml
[package]
name = "a"
version = "0.1.0"
edition = "2021"
[dependencies]
anyhow = "1.0.5"
itertools = "0.13"
# b/Cargo.toml
[package]
name = "b"
version = "0.1.0"
edition = "2021"
[dependencies]
Then
cargo add -p b itertools
cargo add -p b anyhow
Expected results
# b/Cargo.toml
...
[dependencies]
anyhow = "1.0.5"
itertools = "0.13"
Actual results
[dependencies]
anyhow = "1.0.95"
itertools = "0.14.0"
Possible Solution(s)
Look through the workspace and pick a version (more precisely, a "requirement") already used elsewhere, by default. The precise algorithm needs a little thought, but it should probably prefer later versions (requirements that would select later versions).
Notes
I'm filing this as a bug because in a medium to large workspace the default behaviour easily results in duplicated crates. Feel free to downgrade this ticket if you feel like it.
Also, I'm not sure what compatibility guarantees cargo add offers. It's possible that any new/changed behaviour would have to be conditional somehow.
(Also, I wonder if the version selection is MSRV-aware?)
Version
cargo 1.85.0-beta.8 (d73d2caf9 2024-12-31)
release: 1.85.0-beta.8
commit-hash: d73d2caf9e41a39daf2a8d6ce60ec80bf354d2a7
commit-date: 2024-12-31
host: x86_64-unknown-linux-gnu
libgit2: 1.8.1 (sys:0.19.0 vendored)
libcurl: 8.9.0-DEV (sys:0.4.74+curl-8.9.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w 11 Sep 2023
os: Debian n/a (trixie) [64-bit]
(edited to normalise ordering in example Cargo.toml's.)