When no version is specified, reuse existing locked versions

[epage]

Problem

When developing #12039, I ran cargo add clap into the xtask but that picked the latest clap version, causing more churn to the lockfile than I thought was appropriate for my change.

Proposed Solution

Check the lockfile for the highest version that is semver compatible with the latest version.

• By limiting it to semver compatible, this avoids the "some random dev dependency is using an old clap" problem (criterion)

Alternatives

• Pick from non-dev dependencies
• Pick only if a workspace member depends on it
• Reject this in favor of workspace inheritance

Notes

We already will auto pick

• version from alternative dependency table from same package
• inheriting from workspace.dependencies

See also killercup/cargo-edit#41

[epage]

I originally rejected killercup/cargo-edit#41 because of workspace inheritance but I find that I don't tend to use it for dependencies, preferring to keep that information more local

[dev-ardi]

I wouldn't even oppose to having an opt-in option to use older versions.
I would also expect cargo add crate@latest to keep current behavior.
And now that I'm asking cargo add crate@workspace should work too.

[epage]

Flags work well when the user runs the command very regularly or if they realize they missed it and can go back, find it, and run it again.

Thats not the case with cargo add, especially in picking versions since cargo add foo && cargo add foo --some-flag-affecting-default-version will mean that a version is already selected and the flag will do nothing. Because of this, we try to provide a reasonable heuristic picking the version.

Flags also come with a cost. The more knobs you offer users, the more they have to search for to find what they are doing or give up and not use the nice feature. The more features we add, the lower the value users get for that feature and every other feature in cargo add.

By default cargo add will already pick

• A version from another dependency table in the same package, assuming you'll want to use the two versions in sync
• Inherit from an existing workspace.dependencies entry

#10608 is exploring heuristics to add dependencies to workspace.dependencies.

There is no cargo add <crate>@latest, see #10741.

[epage]

While I previously avoided workspace.dependencies more generally, now its for concrete, fixable problems.

from #15180 (comment)

I hesitate in us moving forward with this because I feel like inheriting dependencies is not mature enough

• Poor interaction between workspace dependencies and default-features #12162

• Its easy to look at a manifest-dir to see if a breaking change occurred until you start inheriting dependencies. If we had a good story around cargo-semver-checks, that'd be fine. However, that is likely blocked on public dependencies which is blocked on the quality of the lint, see https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/public.2Fprivate.20deps.20without.20rustc.3F/near/471031580