Nix and Bazel: The Odd Couple of Build Tools
summary
Argument: Nix artifacts are not relocatable so binaries live in Nix store with embedded interpreter and DT_RPATHs, which breaks Bazel remote execution, container images and tarball distribution (example: waf2 compress fails with no such file or directory when RBE runs it). Nix evaluation is slow at scale and often re-evaluates thousands of derivations, blocking analysis. Teams cannot easily patch Nix packages or use Bazel tests. Solution adopted is Bazel + bzlmod or wrapping third‑party builds in Bazel, trading Nix convenience for a single, reliable execution model.
AI-written summary · about
chapters (9)
- 0:00Nix and Bazel intro
- 1:03Runtime dependency paths
- 3:11Nix deps remote failure
- 4:55Fixing Nix integration issues
- 6:01Bazel without Nix
- 7:07Nix evaluation slowdowns
- 8:09Docker with Nix deps
- 9:11Wrapping Bazel with Nix
- 9:53Nix vs Bazel verdict
related talks
40mBut It Builds on My Machine!: Building Deterministic OCI Images With Nix
01h 01mIntroduction to Bazel
34mNix for developers and ops
21mDebugging and fixing build non-determinism with Bazel
05mNix: A functional package manager for your C++ software stack
18mReproducible Builds with Bazel
31mHey Dad, What's Bazel?
15mBuilding Developer-Friendly Spaces: Nix in a Nutshell