Skip to content
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

cargo add should check public transitive dependencies when auto-picking a version #13038

Open
Tracked by #44663
epage opened this issue Nov 22, 2023 · 2 comments
Open
Tracked by #44663
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-add S-accepted Status: Issue or feature is accepted, and has a team member available to help mentor or review Z-public-dependency Nightly: public-dependency

Comments

@epage
Copy link
Contributor

epage commented Nov 22, 2023

Problem

When adding a new dependency that is meant to interact with another one (ie its a public transitive dependency), you need the versions aligned.

Proposed Solution

When cargo add foo auto-selects the version requirement, we shouldn't just check other dependency tables to see if the dependency is present but we should first check public transitive dependencies of the table we are editing.

We also should check the public dependencies of the package being added to see if there is a better match

ie in the ideal case we would allow either of the following

$ cargo add clap_complete@3
$ cargo add clap  # pick v3 instead of v4
$ ...
$ cargo add clap@3
$ cargo add clap_complete  # pick v3 instead of v4

How well it works in practice, it will be seen.

Notes

No response

@epage epage added C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-accepted Status: Issue or feature is accepted, and has a team member available to help mentor or review Z-public-dependency Nightly: public-dependency Command-add labels Nov 22, 2023
@linyihai
Copy link
Contributor

claim first, question it later ~ @rustbot claim

@linyihai linyihai removed their assignment Nov 23, 2023
@linyihai
Copy link
Contributor

I'm trying to figure out what's possible.

$ cargo add clap_complete@3
$ cargo add clap  # pick v3 instead of v4
$ ...
$ cargo add clap@3
$ cargo add clap_complete  # pick v3 instead of v4

The two examples above seem completely different to me and may require different solutions.

The prerequisite is that clap_complete depends on clap and is public, that is to say clap is clap_complete public dependency.


Case 1: run cargo add clap_complete@3 firstly

For the first example, we run cargo add clap_complete@3, then the exact version of clap can be found in Cargo.lock.

cat Cargo.lock | grep -C 3   clap
checksum = "bef38d45163c2f1dde094a7dfd33ccf595c92905c8f8f4fdc18d06fb1037718a"

[[package]]
name = "clap"
version = "3.2.25"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "4ea181bf566f71cb9a5d17a59e1871af638180a18fb0035c92ae62b705207123"
dependencies = [
 "bitflags",
 "clap_lex",
 "indexmap",
 "textwrap",
]

[[package]]
name = "clap_complete"
version = "3.2.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "3f7a2e0a962c45ce25afce14220bc24f9dade0a1787f185cecf96bfba7847cd8"
dependencies = [
 "clap",
]

[[package]]
name = "clap_lex"
version = "0.2.4"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "2850f2f5a82cbf437dd5af4d49848fbdfc27c157c3d010345776f952765261c5"
--
name = "tt"
version = "0.1.0"
dependencies = [
 "clap_complete",
]

So a possible outline comes to my mind, when people run cargo add clap

  • get a resolver from Cargo.lock in the beginning
  • get the clap version from the resolver and pass it to crate_spec

the resolver records the clap version, and clap is a public transitive of clap_compete, then the version "3.2.25" will be picked up.
Do you think this idea will work?


Case 2: run cargo add clap@3 firstly

But if people run cargo add clap@3 firstly, then the resolver will not records the version about clap_complete. In this case, we can't get the compatible version of the dependency to be added through resolver.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-add S-accepted Status: Issue or feature is accepted, and has a team member available to help mentor or review Z-public-dependency Nightly: public-dependency
Projects
None yet
Development

No branches or pull requests

2 participants