Skip to content

cargo add version should default to requirement already present in workspace #15195

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ijackson opened this issue Feb 17, 2025 · 1 comment
Closed
Labels
C-enhancement Category: enhancement Command-add S-triage Status: This issue is waiting on initial triage.

Comments

@ijackson
Copy link
Contributor

ijackson commented Feb 17, 2025

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.)

@ijackson ijackson added C-bug Category: bug S-triage Status: This issue is waiting on initial triage. labels Feb 17, 2025
@epage epage added C-enhancement Category: enhancement Command-add and removed C-bug Category: bug labels Feb 17, 2025
@epage
Copy link
Contributor

epage commented Feb 17, 2025

This is one of the possible solutions for the problem in #12046 so I'm closing in favor of that. If there is a reason to keep this open, let us know!

btw a workaround is to use workspace.depencies. iirc those will automatically be selected.

@epage epage closed this as not planned Won't fix, can't repro, duplicate, stale Feb 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: enhancement Command-add S-triage Status: This issue is waiting on initial triage.
Projects
None yet
Development

No branches or pull requests

2 participants