bazelbuild / bazelbuild/rules_rust
crate.from_spec module extension is not reproducible
- Dominant language
- Starlark
- Stars
- 843
- Forks
- 651
- Avg merge
- 2d 18h
- Merged PRs (30d)
- 15
Description
Protobuf [uses](https://github.com/protocolbuffers/protobuf/blob/75581bff86f188092637bf782e97c99a38e8ac46/MODULE.bazel#L83) the `crate.from_spec` module extension. Unfortunately, this extension is [not reproducible](https://github.com/bazelbuild/rules_rust/blob/c07cb1b5e1bec3184239c28bdddd6c5a0a97d634/crate_universe/extensions.bzl#L469-L472). What this means in practice is that any project that uses protobuf via bzlmod and wishes to check in its lockfile must regenerate that lockfile on all OS/arch combinations it supports.
This is _very_ painful, especially because there is only one `MODULE.bazel.lock` file (rather than one per OS/arch combination, like Python requirements files), so I believe I can't simply run lockfile-updating CI jobs in parallel and then apply the git patches they generate. (I expect the patches will conflict!) Instead, I'll need to run them one at a time, and apply patches in between.
I see a few possible solutions here:
1. Have protobuf check in their Cargo lockfile and not use the `crate.from_spec` extension.
2. Fix `crate.from_spec` by specifying `-minimal-version`, as suggested in [the comment]((https://github.com/bazelbuild/rules_rust/blob/c07cb1b5e1bec3184239c28bdddd6c5a0a97d634/crate_universe/extensions.bzl#L469-L472)) @dzbarsky left in https://github.com/bazelbuild/rules_rust/pull/2575.
3. Ensure `MODULE.bazel.lock` file updates from different OS/arch combinations can always be patched in any order (thus ensuring the patches can be generated in parallel by CI). This would be a FR for bzlmod.
I'm not sure how options 1 and 2 compare in terms of difficulty, or how feasible option 3 is. Are there any better ways out of this situation?
@fmeum @Wyverald
Originally ran into this here: https://pwbug.dev/354274498#comment41
Contributor guide
Assessment
This issue has not been assessed yet.