bazel_8: init at 8.4.1

[boltzmannrain]

The setup is based on bazel 5,6,7 in nixpkgs but is significantly
different codeline-wise. There's a bit less patching, all patches
are via patch files and other small tweaks.

Bazel 8 build

With 8.4.1 bazel dist archive is enough for air-gapped build removing
the need for FODs or src-deps.json, and in turn we no longer need
existing bazel binary to bootstrap the build.

enableNixHacks patch is removed, bazel-examples repo is used
as passthru.tests (cpp, java, rust) via new bazel_8/build-support
helpers.

sed patches are converted to patch files, overall amount of patching
is reduced, if there'd be need for more it can be added with links
to upstream issues or patches, ideally with a regression passthru.tests
item.

Amount of patching may potentially be reduced further, this needs
more feedback using this.

Overall using Bazel on NixOS remains tricky, for non-packaged repos
it may still be most practical to use FHS + extra hacks and patches,
maybe even straight up using Bazelisk and upstream pre-built binaries
in FHS.

buildBazelPackage support

pkgs/build-support/build-bazel-package/default.nix is fairly big
with a set of tweaks that may not be necessary with recent Bazel
or may have better alternatives. More work is needed to figure
out compatibility with bazel_8 or other things to unify with bazel_8
helpers.

bazel_8/build-support

Here are fairly minimalistic helpers to aid building Bazel packages
using Bazel 8 features. For now only testes on bazel-examples repo.

patching.nix: just a helper to inject patches into Bazel external
dependencies

bazelDerivation: helps to compose Bazel commandline and consume
repository_cache, vendor_dir, registry all related to external
dependencies management

bazelPackage: two-stage derivation similar to buildBazelPackage,
having options for repository_cache (pure fetches) or vendor_dir
(unpacked fetches, further patchable)

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[arximboldi]

Reporting that I've tried this and it seems to be working pretty well!

Ping @NixOS/bazel as this seems to have gone unnoticed

[lopter]

Same, I have been successfully using that on Linux & Darwin x86_64.

I have one ask: can we add bash onto PATH for bazel? (see defaultShellUtils).

This will allow the sh rules to work, which I believe is a sensible thing to do, and I had to do it to use cerisier/toolchains_llvm_bootstrapped.

Thanks for the work!

[boltzmannrain]

I have one ask: can we add bash onto PATH for bazel? (see defaultShellUtils).

I'd prefer to look into it separately after it gets merged, there could be multiple ways to make those rules work which needs some looking into first (long-term would be nice to convert most of current nixos patches to configuration options or patches on bazel side)

Note: 8.3.0 is coming soon too but not released yet, that'll also be a folllow-up

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/3032/5632

[slashformotion]

This can be merged I believe

[boltzmannrain]

I don't have permissions to do that myself..

[boltzmannrain]

Hmm, excluding darwin from platforms didn't help with CI wait time, check on darwin is still pending. Maybe because it was previously requested on this PR?

[emilazy]

Thanks for your work on this!

@boltzmannrain @hzeller Since the Bazel team appears to be inactive, how do you feel about adding yourselves to it (and considering dropping inactive maintainers from it)? The Bazel support in Nixpkgs could clearly use a lot of work and it would be good to have an active maintainer team for that. Being part of the team will also let you use the merge bot to merge PRs opened by @r-ryantm and by committers (though I imagine getting @r-ryantm to create automatic update PRs for this would require some passthru.updateScript engineering and some good fortune).

I realize that a committer to merge the changes is the bigger blocker here. I do not understand Bazel enough to feel qualified to give a truly thorough review of this, but the code does not scare me any more than the existing Bazel derivation, so I’m okay merging this once builds are verified. An update to the latest version would be great, but can come in a follow‐up PR. FWIW, it would be very nice to see this package become version‐generic rather than copy‐pasting, but it seems like the Bazel 8 build is different enough that a fresh start makes sense.

Hmm, excluding darwin from platforms didn't help with CI wait time, check on darwin is still pending. Maybe because it was previously requested on this PR?

ofborg will still try to queue things up on Darwin even if they’re marked as unsupported, because it only finds out that the package is unsupported once the queue entry runs. Unfortunately ofborg hasn’t gotten as much attention as it needs lately and the Darwin runners in particular are very overloaded. I can help verify a Darwin build if you remove the exclusion commit. You can ping @NixOS/darwin-maintainers for that kind of thing in future, too.

[boltzmannrain]

For latest release 4.0.0rc1 is there with release planned in couple days. I was thinking to keep this PR in ofborg queue, and maybe create a concurrent PR for newest version with darwin excluded so maybe it has better luck. But since ofborg will still queue builds it won't help then

[boltzmannrain]

Updated to use 8.4.0, this allowed to remove couple more patches. Applied other suggestions from comments here and from Gemini code assist from boltzmannrain#1

Keeping platforms = linux + darwin, on my machines all are building fine, and removing won't help skip the darwin queue anyway.

[boltzmannrain]

For updates to Bazel maintainers team, there's also ci/OWNERS file to consider #375056 (comment) Haven't touched either yet, probably best be done via separate PR

[fzakaria]

Please let me know how I can help to get this approved.
I'm interested in Bazel --
(My own selfish goal would be to see a very simple easy buildBazelPackage that just works ;P )

[boltzmannrain]

I thought ofborg builds are required so was waiting for them to pass on macos, but looking at #424273 and that all (required) checks are green ✔️ in github UI maybe that's not a blocker (macos builds also work on my machines, but don't know if anyone else tried them, running https://github.com/Mic92/nixpkgs-review independently won't hurt)

Otherwise PR is now updated to latest 8.4.1 and I'm not aware of any merge blockers.

[ryand56]

Ignore the Ofborg darwin/macos builds, those usually take forever.

[donn]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 400941
Commit: fae41a5ee90b944d3bb461038ccb0fb168373ea6

---

x86_64-darwin

✅ 1 package built:

• bazel_8

---

aarch64-darwin

✅ 1 package built:

• bazel_8

[DolceTriade]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 400941
Commit: fae41a5ee90b944d3bb461038ccb0fb168373ea6

---

aarch64-darwin

✅ 1 package built:

• bazel_8

[emilazy]

Thanks for sticking with this work! Hope this can help improve the Bazel + Nix situation :)