MSRV-aware resolver

Posted Jan 15, 2025 18:25 UTC (Wed) by apoelstra (subscriber, #75205)
In reply to: MSRV-aware resolver by farnz
Parent article: Rust 1.84.0 released

> I'd have to manually identify this problem, and change the dependency specification to clap = ">=4.0, <4.3.24" to maintain my MSRV.

In general, you don't want to add `<` conditions to your dependency specification. It is true that if you merely had `clap = "4.0"` then cargo may pull in 4.3.25 which is in violation of your MSRV, and users will see a build failure by default. But your downstream users can fix this by running `cargo upgrade -p clap --precise 4.3.25`.

If you were to specify `clap = ">= 4.0, < 4.3.24"`, and your users wanted to use a project alongside yours with `clap = "4.3.25"` (presumably both the user and this other dependency have a higher MSRV) then the project won't compile and there is nothing the user can do to correct the situation.

One place where there is missing tooling in the Rust ecosystem is that there is no way for you, as project maintainer, to tell your users that they need to pin their dependencies in this way. The best you can do is put these `cargo update -p` invocations into your README and hope that they are noticed. (Users running old versions of rustc are likely familiar with this because this sort of breakage is constant in the Rust ecosystem, which is dominated by crates that use new compiler features almost as soon as they are available.)

As a library author, you might hope that you can solve this by providing a lockfile which specifies a particular version of clap. However, lockfiles for libraries are only applied when building the library in isolation (which only developers of the library itself ever do). Downstream users of the library ignore the lockfile entirely. So it basically serves as a hard-to-read form of documentation.

It would be nice if there were a tool -- and I hope one day to find the time to write this -- which could manipulate lockfiles to do things like:

* Merge two lockfiles, preferring the earliest or latest (or "latest which supports a given MSRV") in case of conflicts. In particular, being able to merge dependencies' "blessed lockfiles" into your project; or being able to merge only specific parts of a lockfile.
* Viewing lockfiles as first-class objects and being able to query them, split them, edit them, etc

MSRV-aware resolver

Posted Jan 15, 2025 18:31 UTC (Wed) by farnz (subscriber, #17727) [Link]

With the MSRV-aware resolver, it becomes a lot simpler; I specify that my MSRV is 1.64, and when I use Cargo commands in my project, it refuses to consider 4.3.24 or later, since they declare a higher MSRV. If you use my crate in a project with no MSRV, or an MSRV of 1.74 or later, Cargo will consider 4.3.24 or later, since the Cargo.lock is project-wide, not crate-specific. I can continue to specify clap = "4.0", and get an MSRV-compatible version for tests etc, while allowing downstream consumers to increase their MSRV and get a later clap version.