You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I did some experiments on [this
example](https://github.com/bazelbuild/rules_rust/blob/e38fa8c2bc0990debceaf28daa4fcb2c57dcdc1c/examples/hello_world/MODULE.bazel#L25-L30)
to evaluate the `lockfile` attribute vs. using `MODULE.bazel.lock`:
I ran `bazel test //... --profile=...`. After every run, I did a `bazel
clean && bazel shutdown` to start clean.
1. Run (`MODULE.bazel.lock` file only): No `cargo-bazel` call found in
the profile generated
1. Run (add the `lockfile`, run `CARGO_BAZEL_REPIN=true bazel mod tidy`,
then `bazel test`): No `cargo-bazel` call found in the profile generated
1. Run (delete `MODULE.bazel.lock`): `cargo-bazel` was called, but cargo
splicing was very fast. The `MODULE.bazel.lock` was recreated
1. Run (delete`MODULE.bazel.lock` and run with `--lockfile_mode=off`):
`cargo-bazel` was called, similar to above
This suggests:
* If you have the `MODULE.bazel.lock` file up to date, no `cargo-bazel`
is called regardless of using the `lockfile` or not
* If the `MODULE.bazel.lock` is not tracked in VCS the `lockfile` seems
to be helpful and should be used
* Comparing the `MODULE.bazel.lock` file and the `lockfile` a bit more
in detail, shows they store similar information. The `lockfile` is a bit
more well structured json (for the rust specific content) while the
`MODULE.bazel.lock` file seems to store the entire content generated for
every crate in a single string.
0 commit comments