repository·master·Indexed 18 days ago
https://github.com/tweag/rules_nixpkgsBazel rules for hermetically importing Nix and Nixpkgs dependencies into Bazel builds. It provides mechanisms to import Nixpkgs via Git, local expressions, or Bzlmod module extensions, and allows exposing Nixpkgs packages and toolchains as Bazel targets. The library includes specialized modules like rules_nixpkgs_core and rules_nixpkgs_cc to ensure reproducible and incremental builds for external system packages.
rules_nixpkgs Rust rules to import rust, rustfmt, and rust_analyzer toolchains directly from Nixpkgs into your Bazel workspace. This is achieved using the nixpkgs_rust_configure function.rules_nixpkgs allows you to use Nix-built packages as drop-in Bazel toolchains.
rules_nixpkgs_cc) to automatically register the toolchain. This avoids requiring users to manually use use_repo, which can lead to unpredictable repository names.The nixpkgs_python_repository rule is intended to mimic the rules_python API. It provides a requirement function that creates labels in the format @{nixpkgs_python_repository_name}//:{package_name}.
Warning: While depending on these labels directly works, the internal layout may change. For long-term stability, it is recommended to define and import your own requirement function to manage these labels.
rules_nixpkgs repository is split into multiple interdependent Bazel modules. Because standard Bazel overrides like local_path_override are restricted to the main module, and command-line --override_module flags do not support relative paths, a local Bazel registry is used for testing and local development. This allows you to manage dependencies between the various modules within the repository effectively.Bazel aims for hermetic and reproducible builds, but by default, it often relies on the host environment's global state (like the C++ compiler in PATH or system library versions). This can lead to non-reproducible builds where the same code produces different artifacts on different machines.
rules_nixpkgs solves this by allowing Bazel to provision external dependencies and toolchains via the Nix package manager. This approach provides:
rules_nixpkgs does not invalidate unrelated targets.apt update commands.In Bzlmod, module extensions are identified by the Starlark module and name they are imported from, rather than by reference equality of the extension object.
Warning: Do not attempt to re-export a module extension from a different location. If you import the same extension from two different .bzl files, Bazel will evaluate it multiple times in separate namespaces, which can lead to unexpected behavior or undetected cycles.
With the introduction of Bazel's Bzlmod dependency management, rules_nixpkgs has transitioned from using repository rules in WORKSPACE to using Module Extensions in MODULE.bazel.
To prevent dependency bloat and version conflicts, rules_nixpkgs is split into several specialized Bazel modules. Instead of one monolithic rule set, you should use the module relevant to your language to ensure you only pull in necessary transitive dependencies (e.g., using rules_nixpkgs_cc will pull in rules_cc, but won't pull in Go or Python rules).
rules_nixpkgs_core, rules_nixpkgs_cc).Nix packages (Nix derivations or store paths) can be built, fetched, and imported into Bazel.
When defining a package via a module extension tag, you can specify:
pkgs.hello). If not provided, it defaults to the tag name.import <nixpkgs> { config = {}; overlays = []; } if no file is provided..nix file providing the attribute.NIX_PATH entries.BUILD file or a custom BUILD file (provided as an inline string or a source file).You can use a C++ toolchain to compile non-C++ libraries (e.g., using Clang/LLVM for CUDA or HIP code). There are two ways to achieve this:
cc_lang = "none" in the nixpkgs_cc_configure call. Then, in your cc_library or cc_binary rule, provide the appropriate compiler flags via copts (e.g., copts="-x cuda").nixpkgs_cc_configure(..., cc_lang = "cuda") to set the toolchain's primary language mode.# Method 1: Disable C++ mode and use copts
nixpkgs_cc_configure(..., cc_lang = "none")
cc_library(
name = "my_cuda_lib",
copts = "-x cuda",
...
)
# Method 2: Set toolchain language directly
nixpkgs_cc_configure(..., cc_lang = "cuda")The rules_nixpkgs implementation for Bzlmod is subject to several Bazel-specific constraints that affect how you manage Nix repositories and packages:
"nixpkgs"), the extension must either unify them into a single workspace or generate unique names to avoid collisions.use_repo stanza.