Verify older MSRV while using new V3 dependency resolver

[nyonson]

I'd like to use the new V3 cargo dependency resolver in my library, however, this makes it difficult to verify the MSRV if that version doesn't know of the new V3 resolver:

`resolver` setting `3` is not valid, valid options are "1" or "2"  

Any recommendations to get around this? I am attempting to just modify the Cargo.toml in CI, but is feels very hacky.

[foresterre]

Hmm you set the resolver in the Cargo manifest I assume, i.e. this is not the lock file? (If it is the lock file, you can use --ignore-lockfile).

An argument could be made that setting a resolver version to something only more recent Rust versions (or really Cargo here) support should result in the MSRV being such a recent version.

What is your use case? Can you compile your crate using older cargo versions which do not support resolver = 3? Or do you rather want to more strictly resolve the MSRV for the rust code and bypass whether Cargo is compatible (this used to be supported, although most commonly cargo is used anyways and is also relevant, yet I want to bring it back in the near future).

---

If it is more foundational, I will have to take a closer look at the impact (not at a pc right now).

[nyonson]

Yep, it is set in Cargo.toml with the package.resolver config.

It does feel like I am fighting the current here, so maybe I have a bad assumption. My thinking is that for a library that supports an MSRV, it is nice to see that there is in fact a set of dependencies which work with the MSRV (which resolver v3 finds for us). The consumer of the library will most likely have a different MSRV and resolve a different set of dependencies, but still feels good for the library maintainer.

As the maintainer, I also want to make sure my library's code also builds with the MSRV compiler. Technically, the dependencies are already resolved in the lockfile, so it really doesn't have to care about the setting. However, cargo barfs if it sees a resolver version it doesn't know. Right now i just manually edit the manifest, but its pretty brittle code,

[foresterre]

Yeah, that does seem like a valid use case. I'll make an e2e test and will prototype some solutions, to figure out the best options.

I do wonder whether older cargo versions see that resolver number too when depending on such a library (I mean they get a Cargo manifest too), or whether the field is removed (probably when the crate is packaged (?))

Thanks for the report!

[nyonson]

I am thinking of just adding a small check to my CI pipe like the following, it just needs a stable toolchain 1.85.0+. I think #1093 will make it even better (although I don't think the underlying cargo check call should modify the lockfile in this case).

# Check code with MSRV compiler.
_test-msrv:
  # Generate a lockfile which "fallsback" to the highest dependency
  # versions which also work for the MSRV. If none fit the MSRV, then
  # the constraints take priority, the MSRV might implicitly be
  # raised. So we check the build to see if it introduces any
  # code which cannot be compiled with the MSRV. 
  CARGO_RESOLVER_INCOMPATIBLE_RUST_VERSIONS=fallback cargo update --verbose;
  # Handles creating sandboxed environments to ensure no newer binaries sneak in.
  cargo install cargo-msrv@0.18.4
  cargo msrv verify --all-features

This means I don't have to depend on the package.resolver setting in the manifest at all, and kind of demoted the roll of Cargo.lock in the library since this will just overwrite it.

[foresterre]

Glad you found on a workaround that works for you. I'll still be looking to implementing something that works in the general case where someone does specifies a resolver in the future.