Maintain a separate lockfile for HEAD Bazel

[Wyverald]

The MODULE.bazel.lock file we have in our source tree is generated by the version of Bazel specified in the .bazelversion file. We currently use this lockfile for our distribution archives, which means whenever we increment the lockfile version, we need to manually transform the checked-in lockfile to make it work with HEAD Bazel too.

This commit just checks in a lockfile for HEAD Bazel and removes that hack. This separate lockfile is updated by running bazel run //src/test/tools/bzlmod:update_default_lock_file. If it goes out of date, the distfile tests will complain.

[fmeum]

Looks good to me.

Just so that we have considered it: couldn't we maintain MODULE.bazel.lock.dist as the output of a rule that consumes MODULE.bazel and runs bazel mod deps on it with Bazel built at HEAD? Then we wouldn't need to update it manually.

[Wyverald]

Just so that we have considered it: couldn't we maintain MODULE.bazel.lock.dist as the output of a rule that consumes MODULE.bazel and runs bazel mod deps on it with Bazel built at HEAD? Then we wouldn't need to update it manually.

that was my first thought too, but the input to that rule is more than just MODULE.bazel -- it's also any .bzl files loaded, and any files they read, etc. I fiddled around with it a little bit before deciding that 1) it's too much work to figure out which files to include as input and 2) we already need to run the update_default_lock_file thing anyway.

[meteorcloudy]

This change has the downside that any MODULE.bazel file change will require the developer to update the dist lock file, which requires running update_default_lock_file and building Bazel. Currently, only changing MODULE.tools or relevant bzl files will require the developer to run update_default_lock_file.

but the input to that rule is more than just MODULE.bazel -- it's also any .bzl files loaded, and any files they read, etc.

For the bootstrap build, we actually only need the Bazel module resolution to be updated to prevent accessing BCR, module extensions can just rerun. That's because 1) the maven repo is already overridden, 2) other required module extension generated repo already has repo cache in the distfile. Therefore, I think it's safe to generate the lockfile with a build rule without specifying all inputs.

[Wyverald]

Thanks for the tip! Sent #21302 instead.