Differences between the lockfile formats

[dae]

I've been using crates_universe in a private repo for a while, and it has been working out well. The only thing I found a bit awkward was the lockfile handling, so I was excited to see cargo-bazel adds support for Cargo lockfiles. I just started digging into it further today, and noticed the docs are discouraging their use:

From https://abrisco.github.io/cargo-bazel/rules.html#crates_repository-lockfile:

Bazel lockfiles should be the prefered kind as they're desigend with Bazel's notions of reporducibility in mind.

Could I trouble you to elaborate a bit on what is being lost when using a Cargo.lock file instead of a Bazel one?

What I like about Cargo.lock files is that I can be selective about dependency updates. For example, if I need to pin one dependency to an older or newer version, I can do that while leaving the other crates alone in most cases. This is not to avoid updating the other crates for long periods - I'm not trying to pin them to specific versions indefinitely - but I would like to do those 'update to latest' operations separately, so that I can keep commits relatively atomic. With crates_universe, I got the impression that things like the rules_rust and Rust versions were part of the hash, and I found myself having to run REPIN=1 to get the build to proceed, when I would have preferred to defer the updating of crates to another time.

(the other minor gripe with the custom lockfile was the number of changed lines, which I brought up previously here: bazelbuild/rules_rust#775)

[abrisco]

Could I trouble you to elaborate a bit on what is being lost when using a Cargo.lock file instead of a Bazel one?

The cargo lock files do not contain enough information to be able to immediately produce BUILD files. Additional processing has to be done which requires the "splicing" phase of the rule. I didn't mean to condemn the use of Cargo.lock but it is going to be less performant than using the Bazel lockfiles.

With crates_universe, I got the impression that things like the rules_rust and Rust versions were part of the hash, and I found myself having to run REPIN=1 to get the build to proceed, when I would have preferred to defer the updating of crates to another time

This is also true of cargo-bazel and I think should not need to be. I'm happy to collaborate on how this could be improved.

(the other minor gripe with the custom lockfile was the number of changed lines, which I brought up previously here: bazelbuild/rules_rust#775)

Yeah, I think the lockfile could be reduced but for now I just went with what's easier 😅

Also, thanks for posting this! I don't know if you saw but cargo-bazel has been upstreamed into rules_rust. I just haven't yet gotten around to archiving this project 😅

[dae]

Thanks for elaborating! If the performance hit is just on lock file changes, and not on every Bazel invocation, that doesn't sound too bad. Will give it a try when I get a chance.

Wasn't sure if you wanted bug reports/questions here or on rules_rust - I can post over there in the future if that's preferable.