I own a library in Rust with daily tests running in github pipeline. These tests include MSRV build (currently 1.69.0). These MSRV tests fail from time to time when Cargo decides to resolve some package to version not compatible with the specified rust version.
Here's a most recent example on two consecutive days (no code changes in between):
tokio v1.38.1
. Builds fine with 1.69.0tokio v1.39.1
. Fails to build despite tokio
correctly specifying rust-version = 1.70.0
(bumped here, before release here)Again, tokio v1.39.1
says that it requires rust-version = 1.70.0
. My own Cargo.toml
specifies a very lax version:
#...
[dev-dependencies]
tokio = { version = "1", features = ["full"] }
#...
Because it's a dev dependency and I don't want to deal with bumping it regularly, just use the latest compatible version everywhere.
For now I pinned tokio
stricter, but the same problem happened in past with dependencies
, which was a huger problem I failed to deal with appropriately (just bumped MSRV due to dep resolution failure).
This is a library, so Cargo.lock
is not a thing I can leverage (ref) to deal with this. What am I missing? Why is cargo
resolver bringing package versions ignoring their rust-version
constraint?
The cargo dependency resolver is not MSRV-aware, but steps are being made to support that.