`cargo hack` ignores my MSRV compatible `Cargo.lock`, preventing me from testing my MSRV

taiki-e / cargo-hack

Cargo subcommand to provide various options useful for testing and continuous integration.

Apache License 2.0

612 stars 30 forks source link

`cargo hack` ignores my MSRV compatible `Cargo.lock`, preventing me from testing my MSRV #234

Open epage opened 7 months ago

epage commented 7 months ago

UPDATE(taiki-e):

The situation here has been improved, and the latest cargo-hack overwrites the existing Cargo.lock only when it is necessary to work around old cargo bugs (https://github.com/taiki-e/cargo-hack/pull/242). If you want to ensure that the existing Cargo.lock is respected in all cases, please use --locked.

While I got cargo-hack working in Cargo, it seems Cargo's dependencies align on MSRV. I tried adopting it in a project where MSRVs is misaligned with dependencies and was surprised that my curated `Cargo.lock was blown away to solve #105.

epage commented 7 months ago

Looking for what an agreeable solution is.

Personally, I'd prefer this behavior to be either

Opt-in with a --generate-lockfile flag
Auto-detected on if a Cargo.lock was already present (since the concern was with the cargo metadata call)

But looking for what is an acceptable solution that I can go implement so I can use this.

taiki-e commented 7 months ago

Cargo itself can be free to modify the lockfiles as long as no --locked or similar is passed, right? If so, I think we could just skip the use of generate-lockfile when those flags are passed so that we can get closer to that behavior.

taiki-e commented 6 months ago

I think what I mentioned at the end of https://github.com/rust-lang/cargo/pull/13523#issuecomment-1975027985 is the only way we can do well here without additional flags or breaking changes.

taiki-e commented 5 months ago

Considering cargo's behavior around weak dependencies and namespace features (https://github.com/eupn/macrotest/pull/108#issuecomment-2028018098), I feel it would work well to call generate-lockfile only if the MSRV is pre-1.60.

I think it was around 1.47 or 1.37 that there was a problem with the new lockfile being a completely incompatible format, and there was a compatibility issue before and after 1.51, but the above logic covers those too.

Of course, if future cargo introduces compatibility issues, the number of versions requiring generate-lockfile will probably increase.