Bzlmod module resolution transition from WORKSPACE in Bazel 6+
0 reputation · 04 Nov 2024, 02:47 UTC
0 reputation · 04 Nov 2024, 02:47 UTC
Repeatable development environments in Bazel depend on hermetic sandboxing, toolchain pinning, and deterministic dependency resolution.
Bazel 6 and later prioritize MODULE.bazel over WORKSPACE, and mixed WORKSPACE and MODULE.bazel mode is supported in recent releases with version-sensitive semantics. The lack of a finalized deprecation or removal timeline for WORKSPACE creates uncertainty about whether to maintain dual configuration for reproducible builds across clean clones.
What compatibility boundary defines module mode activation when both files exist? Is repository name and resolution order guaranteed to be deterministic across supported Bazel versions in mixed mode? Has Bazel published an official deprecation or removal timeline for WORKSPACE?
33275 reputation · 04 Nov 2024, 08:42 UTC
The activation of Bzlmod mode depends on the --enable_bzlmod flag and the Bazel version, rather than the mere presence of a MODULE.bazel file. In Bazel 6, this flag defaults to false, meaning WORKSPACE remains the primary resolution mechanism. Starting with Bazel 7, the flag defaults to true, activating Bzlmod mode.
When Bzlmod is enabled and both files exist, MODULE.bazel is authoritative for dependency resolution. The WORKSPACE file is still evaluated to support legacy repositories not defined in the module graph, but these are subordinate to Bzlmod's resolution.
Determinism is not guaranteed across different Bazel versions in mixed mode. Repository canonical names (e.g., those using tilde suffixes) are implementation details that can change between releases. Furthermore, the resolution order and handling of duplicate dependencies may vary across versions, making the combination of a .bazelversion file and a committed MODULE.bazel.lock the only reliable way to ensure reproducible builds across clean clones.
Bazel has signaled an intent to move away from WORKSPACE, with discussions around disabling it by default in later major releases (such as Bazel 9). However, a finalized, fixed date for the total removal of WORKSPACE has not been officially published as a hard deadline; it remains a phased transition.
bazel version.bazel info or run a build with --announce_rc to see the resolved value of --enable_bzlmod and --enable_workspace.--enable_workspace=false to identify repositories that still rely exclusively on the WORKSPACE file.MODULE.bazel.lock and .bazelversion, then compare bazel query @//external:all across two different clean environments.To provide a more specific recommendation, please specify the exact Bazel version currently in use, as the default behavior shifts significantly between versions 6 and 7.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.