`cargo add`: Be clever and infer version from Cargo.lock

[killercup]

Like @gankro and @filsmick described on Reddit, cargo add could learn to add dependencies with versions that are already used by another dependency.

Let's say I have my-http-thingy = "0.4.2" already in my Cargo.toml. Now, we run cargo add my-url-parser. Instead of fetching the latest version (e.g., 6.6.6), we should first suggest to use 1.3.37 which my-http-thingy already depends on (and which is incompatible to the latest version).

I'm not sure if we should do this in every case. If part of my dependency tree looks like a (0.2.1) → b (0.4.2) → c (0.6.0) → d (1.2.0) and I want to cargo add d, is the version c depends on still relevant? How should we tell this to a user?

Should we give the user a choice or should we only do this when a special argument is given (e.g., --infer-versions, or --keep-dependencies-flat)? (Personally, I thing interactivity is okay for cargo add, even though it might make the code more complex and we should offer an op-out).

[Gankra]

I'd prefer

• Try to find the version in the lockfile
• If that fails, pick the latest

with --latest and --used as overrides to only use one of these strategies (the latter can therefore error).

[yberreby]

I'd say, on cargo add foo:

• if there is no version in the lockfile, pick the latest foo from crates.io
• else, print a warning listing all instances of foo in the lockfile, along with their versions and the corresponding dependency trees, and exit with a message telling the user they can override with --latest or pick a version from the list we just displayed with cargo add foo@<version>.

[killercup]

Good point with the possibly multiple version in the lock file, @filsmick!

By the way, is there a crate that does cool interactive CLIs like Inquirer.js?

[Gankra]

Even though the lockfile contains multiple requested versions, it should have a canonical selected version, right?

I suppose in dire dependency situations it may have to link in multiple versions? I feel like one version is the most common, and there should be a happy-path for this.

[killercup]

I like happy paths! If we have a fallback "indifferent path" which takes the maximum version of all the version of that crate (using semver) it should cover pretty much all bases. (Yes, the indifferent path can also be happy.)

[epage]

An interesting case is if I depend on criterion in my workspace and then do cargo add clap, I'll get clap v2 instead of v3. Maybe I'm biased but I feel like v3 would be the more correct version since you are unlikely to care what criterion uses. Maybe --latest is the right approach then but I feel like for a lot of users, they won't notice until much later in the process.

[BartMassey]

@epage Yeah ignoring dev-dependencies (recursively) would be nice. Idk how hard this is.