Per-crate Cargo.lock checks?

[kornelski]

Would it make sense to adapt cargo-hack for checking dependency version resolution per crate in a workspace? Especially with -Z minimal-versions.

If I have:

• workspace
  • my_crate1
    • serde = "1.0.1"
  • my_crate2
    • serde = "1.0.123"

Then my_crate1 will only be tested with serde v1.0.123, but if I publish it outside of the workspace, someone else could use it with older dependencies I never tested with. The problem is not limited to direct dependencies in the workspace - the same thing can happen with transitive dependencies:

• workspace
  • my_crate1
    • serde = "1.0.1"
  • my_crate2
    • wants_newer_serde = "7"

So I think the hack needed here is to remove crates from the workspace, re-link them as path dependencies if needed (or with [patch]? not sure), and test with individual Cargo.locks.

[taiki-e]

I this this can be done by completing taiki-e/cargo-minimal-versions#23 and then porting it to cargo-hack (or just use it). (Or maybe by implementing #216)

As for the minimal-versions check, AFAIK, the approach described here does not solve the problem of optional dependencies (taiki-e/cargo-minimal-versions#6), so eventually, it would be best to implement the approach I described in tokio-rs/tracing#2015 (comment) in cargo-minimal-versions.

(In general, I would recommend using cargo-minimal-versions (https://github.com/taiki-e/cargo-minimal-versions) for minimal-versions check because it can automatically handle many of the things that can be problematic when doing minimal-versions check (and also supports the cargo-hack options because it calls cargo-hack internally). However, I'm not opposed to adding the ability to use cargo-hack to do that manually.)