Command to update Cargo.lock to minimal versions

[matklad]

From today's meeting.

Problem:

You write a library A, which depends on B, so you put B = 1.0 in A's Cargo.toml. The you run Cargo build, and Cargo greedily pulls B 1.1 into the lockfile. Then you accidentally start depending on features introduced in 1.1, but you don't change Cargo.toml. Your test locally pass, and CI passes as well, and you publish a crate whose Cargo.toml is a lie.

Solution:

Add cargo update --minimal, which generates lockfile picking the minimum possible version of all crates (it's not possible, of course, because there's no total order on dependency graphs, but some heuristics might work well in practice). Then in CI environment you generate the minimal lockfile to make sure you don't accidentally depend on newer than Cargo.toml features.

[matklad]

Note that we can envision some kind of static solution here, for example, by tagging library functionality with #since attribute. However, actually testing things is still needed, because you may depend on a critical bugfix from the dependency.

[carols10cents]

Related: https://github.com/rust-lang/rfcs/blob/master/text/1977-public-private-dependencies.md#changes-to-cargo-publish-lowest-version-resolution

[Eh2406]

This I think would just involve changing

cargo/src/cargo/core/resolver/mod.rs

Line 1088 in 3ed3497

b.summary.version().cmp(a.summary.version())

to depend on an argument; Then bubble that argument up till it is user facing.

[Eh2406]

I am still learning cargo internals, but I would be willing to help someone who wanted to take this on!

[bluetech]

Then you accidentally start depending on features introduced in 1.1, but you don't change Cargo.toml

Perhaps there's some way to tackle this problem head-on? Probably not, but it's interesting to think about. Two possible ways I can think of:

• Force B to add since="1.1.0" annotations to API introduced in v1.1.0. Cargo prevents using APIs added later than the minimal version allowed byCargo.toml.

• Use an automatic tool like https://github.com/rust-lang-nursery/rust-semverver.

[alexcrichton]

@Eh2406 I'd imagine that with yours and @aidanhs's work on the resolver recently it may be relatively easy to encode this as a constraint and have it finish in a hopefully-not-too-long amount of time too!