Consider public dependencies when choosing a version in cargo add (#1… #15966

sadmac7000 · 2025-09-15T05:37:42Z

What does this PR try to resolve?

This change considers public dependencies when adding a new dependency. For example, if you depend on foo, which depends publicly on bar 1.0, and you run cargo add bar, you will now get bar 1.0 even if bar 2.0 is available.

Fixes #13038

How to test and review this PR?

The test suite has been updated with an example scenario. More tests might be warrented to see how this interacts with other features though.

rustbot · 2025-09-15T05:37:47Z

r? @epage

rustbot has assigned @epage.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

src/cargo/ops/cargo_add/mod.rs

epage · 2025-09-16T13:35:50Z

src/cargo/ops/cargo_add/mod.rs

        } else {
-            let latest =
-                get_latest_dependency(spec, &dependency, honor_rust_version, gctx, registry)?;
-
-            if dependency.name != latest.name {
-                gctx.shell().warn(format!(
-                    "translating `{}` to `{}`",
-                    dependency.name, latest.name,
-                ))?;
-                dependency.name = latest.name; // Normalize the name
+            let (package_set, resolve) = resolve_ws(ws, true)?;
+            let public_source = if spec
+                .manifest()
+                .unstable_features()
+                .require(Feature::public_dependency())
+                .is_ok()
+            {
+                get_public_dependency(
+                    manifest,
+                    ws,
+                    section,
+                    gctx,
+                    &dependency,
+                    package_set,
+                    resolve,
+                )
+            } else {
+                None
+            };
+            if let Some((registry, public_source)) = public_source {


Does this belong here or in get_existing_dependency?

Since fuzzy_lookup calls that several times in a loop it's hard to know where to put the resolve_ws call. Could introduce some state outside the callback but it'll be a bit messy.

src/cargo/ops/cargo_add/mod.rs

tests/testsuite/cargo_add/mod.rs

src/cargo/util/toml_mut/manifest.rs

src/cargo/ops/cargo_add/mod.rs

The new method get_dependencies doesn't take a dep key but instead returns all deps. We'll sometimes need this in coming patches, and when we don't need it it's easy to have the caller filter.

…st-lang#13038)

epage · 2025-09-22T16:11:20Z

tests/testsuite/cargo_add/public_common_version/stderr.term.svg

By resolving before Adding, the output becomes unclear where the locking ends and the manifest editing begins

Since this is unstable, we could possibly punt on this

epage · 2025-09-22T16:12:05Z

src/cargo/ops/cargo_add/mod.rs

+        let pkg_ids_and_reqs = resolve.deps(dep_pkgid).filter_map(|(id, deps)| {
+            deps.iter()
+                .find(|dep| {
+                    dep.is_public()
+                        && dep.kind() == DepKind::Normal
+                        && dep.package_name() == dependency.name.as_str()
+                })
+                .map(|dep| (id, dep.version_req().clone()))
+        });


This appear to only go 1 deep for public dependencies but they can be recursive

rustbot assigned epage Sep 15, 2025

rustbot added A-manifest Area: Cargo.toml issues Command-add S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 15, 2025