Repository navigation
Command to update Cargo.lock to minimal versions #4100
Description
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.
Activity
matklad commentedon May 26, 2017
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 commentedon Sep 25, 2017
Related: https://github.com/rust-lang/rfcs/blob/master/text/1977-public-private-dependencies.md#changes-to-cargo-publish-lowest-version-resolution
Eh2406 commentedon Jan 29, 2018
This I think would just involve changing
cargo/src/cargo/core/resolver/mod.rs
Line 1088 in 3ed3497
Eh2406 commentedon Feb 21, 2018
I am still learning cargo internals, but I would be willing to help someone who wanted to take this on!
bluetech commentedon Feb 22, 2018
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
Bto addsince="1.1.0"annotations to API introduced inv1.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 commentedon Feb 26, 2018
@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!
Eh2406 commentedon Mar 5, 2018
The relevant line of code has moved to:
cargo/src/cargo/core/resolver/mod.rs
Line 664 in af60861
I think we would add a arg to:
cargo/src/cargo/core/resolver/mod.rs
Line 573 in af60861
Dylan-DPC-zz commentedon Mar 5, 2018
Can give this a try :)
Eh2406 commentedon Mar 5, 2018
@Dylan-DPC That is wonderful!
The idea is that the sort on line L664 determines the order that cargo tries versions of packages. Currently from newest to oldest and we want to reverse that order.
Steps as I see it:
-Zflag, like I did in https://github.com/rust-lang/cargo/pull/4990/filesconfig.cli_unstable().minimal_versionsand pass it toRegistryQueryerif minimal_versions {a.summary.version().cmp(b.summary.version()) } else the existing codeminimal_versionsto true and looking at wich test incargo\tests\testsuite\resolve.rsfail.How can I be helpful!?
Dylan-DPC-zz commentedon Mar 5, 2018
Thanks @Eh2406 will take a look whenever I'm free and see how far I get :)
Eh2406 commentedon Mar 5, 2018
If that turns out to be challenging, feel free to ask!
Dylan-DPC-zz commentedon Mar 11, 2018
@Eh2406
L364 of which file?
Eh2406 commentedon Mar 11, 2018
Sorry I wasn't clear
cargo/src/cargo/core/resolver/mod.rs
Auto merge of #5200 - klausi:minimal_versions, r=Eh2406