Rust-version and development dependencies

If my lib has MSRV lower than some of my dev-dependencies have, what should go in my published package on crates.io?

I'm thinking that I should distribute the library and not the integration tests or benches that need higher MSRV so that the package is consistent, i.e. the lib, libtests, and doctests will all work for the MSRV specified in the package. But responsible people run tests, so they should be accessible, like on GitHub (my README would mention that benches are available in the repo and require a higher MSRV). Is there a common practice for scenarios like this? I've seen two options

  • use feature as a gate for optional dev dependencies since those aren't supported yet - I don't see an explicit discussion of MSRV, but seems like the choice is to support the lib
  • put testing in another crate, they're binaries and not part of your lib, they should get a separate MSRV.

Am I missing some existing better approach to this problem? Further, would my assumptions about what to put in the crate deter a user because something would be off or surprising?

Don't worry about dev dependencies at all. Cargo doesn't support testing crates published to crates.io, and there's a plan to completely ignore them when publishing to avoid issues with dependency cycles.

1 Like

Thanks for that, does that mean that my CI should verify MSRV only for the --lib target?

cargo check +$MSRV --lib should be able to check just the library. However, I'm not sure how older Cargo will react to newer deps in the lockfile — if there were incompatible changes to the index or Cargo.toml, it may not be able to download them (likely to happen for MSRV <1.60).

Also consider just increasing MSRV of your library:

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.