cargo hack ignores my MSRV compatible Cargo.lock, preventing me from testing my MSRV
#234
Comments
|
Looking for what an agreeable solution is. Personally, I'd prefer this behavior to be either
But looking for what is an acceptable solution that I can go implement so I can use this. |
|
Cargo itself can be free to modify the lockfiles as long as no |
When using `--rust-version`, the lockfile can be blown away. While that is a problem in of its own, this focuses on an incremental step of not blowing it away if `--locked` is used. This is part of taiki-e#234
When using `--rust-version`, the lockfile can be blown away. While that is a problem in of its own, this focuses on an incremental step of not blowing it away if `--locked` is used. This is part of taiki-e#234
When using `--rust-version`, the lockfile can be blown away. While that is a problem in of its own, this focuses on an incremental step of not blowing it away if `--locked` is used. This is part of taiki-e#234
When using `--rust-version`, the lockfile can be blown away. While that is a problem in of its own, this focuses on an incremental step of not blowing it away if `--locked` is used. This is part of taiki-e#234
When using `--rust-version`, the lockfile can be blown away. While that is a problem in of its own, this focuses on an incremental step of not blowing it away if `--locked` is used. This is part of #234
As a hack in cargo-hack, it doesn't respect lockfiles when doing MSRV testing unless `--locked` is passed in. This adds that so we make sure we don't run into problems with newer, MSRV-imcompatible dependencies come out that break our build. See - https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/gix-ref.20CI.20error/near/423319798 - taiki-e/cargo-hack#234 - taiki-e/cargo-hack#236
|
I think what I mentioned at the end of rust-lang/cargo#13523 (comment) is the only way we can do well here without additional flags or breaking changes. |
chore(ci): Ensure lockfile is respected during MSRV testing As a hack in cargo-hack, it doesn't respect lockfiles when doing MSRV testing unless `--locked` is passed in. This adds that so we make sure we don't run into problems with newer, MSRV-imcompatible dependencies come out that break our build. See - https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/gix-ref.20CI.20error/near/423319798 - taiki-e/cargo-hack#234 - taiki-e/cargo-hack#236
|
Considering cargo's behavior around weak dependencies and namespace features (eupn/macrotest#108 (comment)), 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. |
As a hack in cargo-hack, it doesn't respect lockfiles when doing MSRV testing unless `--locked` is passed in. This adds that so we make sure we don't run into problems with newer, MSRV-imcompatible dependencies come out that break our build. See - https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/gix-ref.20CI.20error/near/423319798 - taiki-e/cargo-hack#234 - taiki-e/cargo-hack#236
UPDATE(taiki-e):
Cargo.lockonly when it is necessary to work around old cargo bugs (Respect lockfile except when necessary to work around old cargo bugs #242).If you want to ensure that the existing
Cargo.lockis 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.
The text was updated successfully, but these errors were encountered: