Merge-friendly Cargo.Bazel.lock

[alexkirsz]

Hey 👋

Working on a large monorepo with hundreds of Rust crates, we're seeing almost constant merge conflicts on the Cargo.Bazel.lock file. For instance, the checksum will always conflict as soon as a dependency changes.

This can lead to frustrating outcomes where you have to chain updates to Cargo.Bazel.lock during the lifetime of a PR, as other PRs get merged that also touch the lockfile. Furthermore, since Github Actions will not run workflows on PRs with merge conflicts, one must always keep their lockfile conflict-free in order to benefit from CI. For the same reasons, using merge queues is also unfortunately out of the question.

The Cargo.lock format was recently updated to optimize it for git merge conflicts. It would be very helpful for Cargo.Bazel.lock to produce as few conflicts as possible.

[dzbarsky]

Cargo.bazel.lock is not necessary when using bzlmod. Perhaps that's a path forward for you?

[UebelAndre]

Cargo.bazel.lock is not necessary when using bzlmod. Perhaps that's a path forward for you?

Can you explain why it’s not necessary? Cargo metadata doesn’t have enough information on its own to be reproducible to Bazel without doing some noticeable computation. I’m still new to bzlmod so curious how it solves this.

[DavidZbarsky-at]

My understanding is that the computation to go from Cargo.lock to Cargo.bazel.lock is pure/reproducible, right?

If so, this works because the Bazel lockfile was essentially a performance optimization, and with bzlmod, Bazel knows to only rerun the module extension when the inputs change. So the Cargo.bazel.lock is still produced, but we don't need to check it in/run the REPIN workflow.