- Bazel's lack of strict sandbox: The current sandbox is able to access almost everything in the root path (
/). As a result, if a rule references a file with an absolute path, Bazel will assume it is a file provided by the operating system and it will not rebuild the target in case the file is updated. - Managing external dependencies: With Bazel it can be difficult to depend on third-party dependencies like complex C/C++ libraries as one often effectively has to port them to Bazel to build them in Bazel, or at least jump through hoops to build with
rules_foreign_cc. With Nix you get access to all of nixpkgs. - Nix's coarse grained builds: Nix is designed and used with full packages as the granularity level. However, it doesn't usually provide fine grained, per-module builds for your own project. This is where Bazel shines and why we combine them.
Development environments
By leveraging Nix, you're gaining access to nixpkgs, one of the biggest package registries and access to thousands of pre-built packages and toolchains that can be used in your Bazel project.
Hermetic builds
Nix provides all the system dependencies as inputs on your projects and helps you achieve fully reproducible builds.
Strict sandbox
All Nix packages are built in an isolated environment, without access to the internet, so it ensures that the build acts like a pure function without side effects or visibility to the outside world.
What is Nix + Bazel?
Bazel is a multi-language build system with support for incremental and remote builds. Nix usually encompasses many things. A package manager, a build system and a configuration language. Since the build system aspect will be handled by Bazel, we'll only refer to Nix as a package manager and configuration language. Head over to Nix docs to learn more about it.
What problems does it solve?
How do I use it?
Take a look at the rules_nixpkgs guide to get started. You can gradually integrate Nix with your Bazel project, without the need to fully commit to it. You can always iterate later depending on your needs and the problems that you're trying to solve.
Below are some of the steps that can be taken into that direction:
- Use Nix to install Bazel and all the related tooling. This is the easiest way to learn more about Nix. Using it as a package manager to provide a development environment.
- Use Nix to install all the necessary third party dependencies of your build. This goes one step further by trying to provide the whole environment for your builds in a versioned and reproducible way.
- Use rules_nixpkgs to provide hermetic builds by providing the toolchains and environments with a tight integration with the Bazel build system. This allows you to fully take advantage of Nix.
Are there any limitations?
- Integration with Nix is possible on all the platforms and operating systems that Nix supports. This includes Linux and macOS, but not Windows.
- Language toolchains are limited by what
rules_nixpkgssupports. Get in touch if you need support for another language. - Bazel remote execution is currently not supported, but it's part of our future plans.