Update request: bazel_7 7.1.2 → 7.3.x

[malt3]

• Package name: bazel_7
• Latest released version: 7.3.1
• Current version on the unstable channel: 7.1.2
• Current version on the stable/release channel: 7.1.0
• [x] Checked the nixpkgs pull requests
• Changelog

Notify maintainers

@NixOS/bazel

---

Note for maintainers: Please tag this issue in your PR.

---

Add a :+1: reaction to issues you find important.

[hjkatz]

cc @NixOS/bazel Can we help prioritize this issue? The Bazel 7.1.* releases have a major functionality bug where remote cache uploads hang indefinitely, see: https://github.com/bazelbuild/bazel/issues/21626 and related issues.

We would normally use a custom derivation where we pass our own version = 7.2.0 into nixpkgs bazel/bazel_7/default.nix but the bazel team upstream changed the lock file format in a minor patch version so now the tests.nix do not pass with this strategy.

[malt3]

@hjkatz please see my comment containing two ideas for solving this. The bazel vendor command will only result in a usable vendor dir after 7.3. So in my eyes, you have the following options:

• implement a proxy as explained in my comment
• Create a manual list of dependencies as a json file that is committed in Nixpkgs

[jtszalay]

7.2.1 is now out: https://github.com/bazelbuild/bazel/releases/tag/7.2.1

[malt3]

Bazel 7.3 will have a fully functional vendoring command!

https://github.com/bazelbuild/bazel/releases/tag/7.3.0rc1

[timothyklim]

Bazel 7.3 will have a fully functional vendoring command!

https://github.com/bazelbuild/bazel/releases/tag/7.3.0rc1

Released 12 hours ago https://github.com/bazelbuild/bazel/releases/tag/7.3.0

[flurie]

Hi, I have a WIP of Bazel 7.3 building on x86_64-linux: https://github.com/NixOS/nixpkgs/compare/master...flurie:nixpkgs:flurie/bazel_73.

Note that (for now) the target is bazel_73.

[hjkatz]

@flurie the hero we need 🙇

[flurie]

Ok to walk through it a little bit:

• I take a built Bazel 7.3, patch it, and wrap it in FHS. I found just patching did not work, but I'm not sure if it needs both at once?
• I use bootstrap Bazel to vendor all deps with bazel vendor for a fixed-output derivation.
• Build Bazel with as little change to the existing drv as possible. To prevent it from fetching things due to timestamps on the marker files, I pin every repo it has in VENDOR.bazel. To enable offline builds, we need to set --repository_disable_download, not --nofetch. Also, for some reason py_binary rules were building python zips, so I had to add --nobuild_python_zip.

It's still kind of messy, but I don't let mess get in the way of a PR unless there's too much of it or I don't have enough time to self-review.

More serious gaps:

• Haven't updated tests. I imagine those will change in the same way so it might be nice either to get out of the bootstrap first or have a single wrapper for the bootstrap that we can use to create Bazel offline drvs, maybe even replacing buildBazelPackage? One thing I don't know is how well bazel vendor performs when you aren't as all-in on bzlmod as Bazel's own build.
• Related to above issue, if bazel vendor is hard to use as a standard deps fetch more generally, should we consider keeping Bazel 7.3 as a separate package for now and moving forward with replacements for things that can use it? That's the only reason I have kept them separate for now.
• No darwin testing. But my understand is that the darwin build is already pretty broken/not practically usable, even though it builds?

If anyone has more info about those gaps, I'll feel more comfortable putting this up for review.

[jtszalay]

:ohno:

2024-08-19 19:26:50 UTC error: hash mismatch in fixed-output derivation '/nix/store/vz0d58c3j2f1vk592k53l3z3ia3i6izf-bazel_deps.drv':
2024-08-19 19:26:50 UTC          specified: sha256-acZOeHBHchotsEG51WfpgR7MGJze88xwnON/DE9IlSo=
2024-08-19 19:26:50 UTC             got:    sha256-+ux/l+IDIZ8VJ7l48u2iJ7DTLt8CasLPW2UH+TGk6LU=

2024-08-19 19:00:34 UTC error: hash mismatch in fixed-output derivation '/nix/store/vz0d58c3j2f1vk592k53l3z3ia3i6izf-bazel_deps.drv':
2024-08-19 19:00:34 UTC          specified: sha256-acZOeHBHchotsEG51WfpgR7MGJze88xwnON/DE9IlSo=
2024-08-19 19:00:34 UTC             got:    sha256-QvpRBilcomdtc74OmZ5PvzZHlm21+55ayQqEk0FlIyI=

bazel vendor seems inconsistent

[flurie]

Good catch. The bazel mod deps almost certainly needs to go, and that should be replaced with vendoring a version of MODULE.bazel.lock, but the one in the repo did not work without getting updated. I vendored a copy (I believe) after making the update. I'll see if I can get the FOD to output something consistently.

I may also be doing something incorrectly since I have little experience with FODs.

[flurie]

@jtszalay has very kindly helped to get the build deps to a reproducible state, and we now have what should be a working derivation (for linux).

[flurie]

https://github.com/NixOS/nixpkgs/pull/338264