Building Bazel projects with Nix has traditionally been also character building - even with the “buildBazelPackage” builder from nixpkgs, the experience often feels less like reproducible engineering and more like a fully-fledged negotiation session.

Broadly speaking there are two main sources of that friction:
1) Bazel has a habit of fetching dependencies lazily - downloading exactly what it needs at a given moment and not a second before. That naturally clashes with the Nix philosophy of declaring all dependencies upfront. Consequently “buildBazelPackage” performs some non-trivial work and patching to vendor all dependencies upfront. This works in principle but in practice tends to generate a steady stream of friction and existential self-questioning.
2) The aforementioned standard builder relies on the nixified version of Bazel. While well-intentioned, it tends to introduce subtle incompatibilities with “vanialla” version, particularly around references to binaries “baked” into the tool (i.e. shebangs), leading to delightful surprises that emerge precisely at the most inconvenient occasions.

To address this, we have built a proof-of-concept of alternative derivation builder, aimed specifically at Bazel 9 (or later) repositories, where bzlmod can be used as an aid in vendoring efforts. This significantly improves the dependency management process and makes it noticeably less painful. In addition, our approach is utilizing the unmodified, prebuilt Bazel binary to avoid any usual suspects of Nix/non-Nix incompatibilities.
The lion share of effort was put into automation of dependency vendoring, so that the most-common use cases may be handled with any specific orchestration from the user.

This talk aims to highlight the existing problems, describe potential solutions and share the proof-of-concept builder with the community.