3.1.12 Layered Ecosystem & Bzlmod Lockfiles
recommendedA Bzlmod language integration can have two lock layers because two resolvers
are doing different jobs. MODULE.bazel.lock records reproducibility state for
module resolution and module-extension evaluation.1 Maven, Python, or Cargo may
also produce ecosystem resolution that maps package names to exact
artifacts.2,3,4
3.1.1 Bzlmod (MODULE.bazel) introduces the module graph, while 3.1.2 Using Extensions explains why extension evaluation can add repositories whose recorded state belongs in the Bazel lockfile.
| Layer | Human authority | Generated evidence |
|---|---|---|
| Bzlmod | MODULE.bazel and extension tags | MODULE.bazel.lock |
| Ecosystem | Maven artifacts, Python requirements, or Cargo manifests | maven_install.json, a Python lock, or Cargo.lock/splicing metadata |
Update the owner, not an arbitrary file
Edit the declared intent, then run the command supplied by the owning ruleset.
rules_jvm_external has pin and repin workflows for
maven_install.json. Python integrations consume or update their chosen lock
format. Crate_universe has Cargo-specific repinning and splicing workflows.
There is no safe universal “update all locks” command.2,3,4
Commit all resulting layers together when one dependency change affects them. Reviewers should see the requested version change, graph changes, and checksum or artifact changes in one unit. If generated resolution looks wrong, regenerate it from its authority rather than hand-editing the symptom.
Make drift fail
CI should run the integration's drift check, pin check, or update target and require a clean diff. That catches the common failure where a manifest or extension tag changes but committed resolution does not. Automation in 6.7.3 Automating Bazel Dependency Updates can open these updates, but it still consumes this same two-layer model.
For the ecosystem-specific commands and file formats, continue with L1.2 Dependency Management (rules_jvm_external), L3.3 pip Dependency Integration, or L6.2 crate_universe.
Treat MODULE.bazel.lock and an ecosystem lock as evidence from different
resolvers. Edit each layer's declared authority, regenerate with that ruleset's
workflow, reject drift in CI, and review related outputs atomically instead of
hand-editing generated resolution.
Footnotes
-
Bazel Lockfile — authoritative
MODULE.bazel.lockgeneration, module-resolution state, and module-extension evaluation state. ↩ -
rules_jvm_external repository map — Maven pinning, repinning, and
maven_install.json. ↩1 ↩2 -
rules_python repository map —
pip.parseand committed Python requirement locks. ↩1 ↩2 -
rules_rust repository map — Cargo lockfiles, splicing metadata, and repinning. ↩1 ↩2
