polarathene
commented
7 months ago More info
My verbosity is an issue for some, I've split this off and tried to condense / organize it. It's purely for reference to support and document the changes in the PR should anyone need more context.
Producing a compatible Cargo.lock for the MSRV
# Resolve a `Cargo.lock` with the latest compatible deps for `rust-version` (1.56.0):
cargo +nightly update -Z msrv-policy
# Minor corrections due to deps lack of proper `-Z msrv-policy` support for the MSRV
cargo update --package memchr --precise 2.5.0
cargo update --package ordered-multimap --precise 0.4.0
cargo update --package tokio-util --precise 0.7.8Validating minimum versions build for MSRV (with 1 less pin)
``` # For verifying minimum versions of direct deps build for the MSRV is supported: # `tokio ="1.27"` (or lower) implicitly prevents needing to pin tokio-util to 0.7.8 (as newer releases require a newer tokio) cargo +nightly update -Z direct-minimal-versions -Z msrv-policy cargo update --package memchr --precise 2.5.0 cargo update --package ordered-multimap --precise 0.4.0 ```The following passes successfully with a Cargo.lock generated from the above:
cargo +1.56.1 check --tests
cargo +1.56.1 clippy --locked --offline --all-targets --all-features -- -D warningsSupplementary info on -Z msrv-policy and pinned versions
Click to view
`-Z msrv-policy` only works on nightly, but ideally resolves within the deps semver range a version that was last known as compatible with `rust-version` in `Cargo.toml`. - This differs from the default resolver which will attempt to satisfy the latest version in semver regardless of `rust-version` compatibility. - This also differs for older toolchains that don't understand newer `Cargo.toml` syntax like introduced in Rust `1.60.0`. - Those would ignore such published crates and resolve to an earlier version of the crate implicitly. These pins are the same versions that would be resolved regardless for the MSRV. - [`memchr 2.6.0`](https://github.com/BurntSushi/memchr/blob/c4bd85f58b763080fff52fbe67081decb2899b33/Cargo.toml#L40) is an implicit dep to quite a few crates in `Cargo.lock`, including the [explicit `nom 7` dep](https://github.com/rust-bakery/nom/blob/9678b061d3ed0a6b8e31ce569e024ec25f3dd354/Cargo.toml#L39). `memchr` only adopted [`rust-version` (1.60) since the `2.6.1` release](https://crates.io/crates/memchr/versions), hence `-Z msrv-policy` is ineffective at resolving without a pin, while the MSRV toolchain resolver would resolve a compatible version as anything newer is considered invalid. - `ordered-multimap` from `rust-ini` has the same problem, except it's history is [more complicated and documented in detail in this comment](https://github.com/mehcode/config-rs/pull/492#issuecomment-1793319804) (_[`ahash` is the issue](https://github.com/tkaitchuck/aHash/pull/181#discussion_r1377129069)_). - `tokio-util` is probably better pinned, that is easier by raising the explicitly pinned `warp` patch version in `Cargo.toml`. [This is also a bit complicated](https://github.com/mehcode/config-rs/pull/492#issuecomment-1793319968), but is an example of when `rust-version` is not correctly maintained.Additional context on deps
**Minimum version:** - `async-trait`: Minimum of `0.1.2` required to support `examples/async_source`. **MSRV bumps:** - `toml`: Newer releases after `0.5.x` series require MSRV 1.60 to 1.66, while the latest `0.8.6` release requires MSRV 1.67. - `ron`: MSRV raised to 1.64 with `0.8.1`. - `rust-ini`: MSRV raised to 1.64 with `0.19.0`, while `0.20.0` (latest) raises again to MSRV 1.71.1. Both due to `ordered-multimap`. - `indexmap`: Next major `2.0.0` raises MSRV to 1.63. - `notify`: The next major (`5.0.0`) keeps the 1.56 MSRV, while the latest `6.0.0` major raises that to MSRV 1.60 - `temp-env`: Newer minor release adopts `rust-version` since `0.3.4` (latest `0.3.6` with MSRV 1.62.1).Without -Z msrv-policy
The following will also support building without generating Cargo.lock with -Z msrv-policy. The versions need to be pinned (in either Cargo.toml or Cargo.lock).
ijackson
matthiasbeyer
These are improvements from an extensive investigation I recently did to simplify maintenance of lockfile generation for the CI to benefit from, while respecting the MSRV.
Commit message:
Click to view
- Slight adjustments to the version fields for compatibility with `cargo +nightly update -Z direct-minimal-versions` with the MSRV of `1.56.0`. - Add `rust-version` field for leveraging `cargo +nightly update -Z msrv-policy` to generate a lockfile that respects the MSRV, and the benefit of downstreams. - Better communicate why `dev-dependencies` are required (_identify associated examples / tests_). - Avoid repeating deps again in in `dev-dependencies`. - Raise fixed `warp` dev dep to an MSRV compatible version (_for a common `tokio-util` implicit dep version_). Simplifies CI lock maintenance.