Open eopb opened 2 weeks ago
Note, we have a --locked
flag which "Assert that Cargo.lock
will remain unchanged".
If this flag is passed, we should not attempt to update the lockfile. Ideally, we should emit a warning if the versions don't align, and --locked
is passed, but we can keep that outside of the scope of this issue.
Technically, a patch will change Cargo.lock
, so --locked
should always fail unless the patch is already applied.
Problem
Quoting from https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html#testing-a-bugfix:
This means that it's possible for a patch created with
cargo-override
to not be selected, despite the version compatibility checks we do. This is due to cargo selecting the latest version with little regard to where it comes from.Suggested solution
First we need to reproduce this issue. I don't want to risk trying to fix something without demonstrating that cargo works in ways that match our assumptions. This test could just be done on a local machine, and once done, a summary posted here.
For the solution, we can automate the guidance from the article above. We already have the exact version of the patch, so a call to
cargo update <pkgid> --precise <version>
should be possible. We shouldn't need to check the lockfile before doing this, since the precise update should be a no-op on correct lockfiles. We can do this for every call tocargo-override
.Open questions
What should we use to call
cargo update
?cargo::ops::update_lockfile
is one option