zb

It's not Rust, it's not production ready, and I haven't actually used it (only read the README and blog posts), but I really enjoy the ideas behind https://github.com/256lights/zb - see https://www.zombiezen.com/blog/2024/09/zb-early-stage-build-... for a list of these ideas.

Good point. Opened https://github.com/256lights/zb/issues/47 to track this idea.

I see the instructions discuss $(mkdir /zb) <https://github.com/256lights/zb#linux-or-macos> and after seeing references to Nix I wanted to ensure this wasn't a hard-and-fast directory choice since macOS has immutable / and it causes no end to the Nix stupidity on macOS

https://github.com/256lights/zb/blob/102795d6cb383a919dd378d... TIL I can also use semicolons on lua tables, not just commas: return derivation { name = "hello.txt"; ["in"] = path "hello.txt"; builder = "/bin/sh"; system = "x86_64-linux"; args = {"-c", "while read line; do echo \"$line\"; done < $in > $out"}; } I like using lua as a DSL, now I like it even more! I've using lua as a html templating language that looks like this: DIV { id="id"; class="class; H1 "heading"; P [[ Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor ]] / EM incididunt / [[ ut labore et dolore magna aliqua. ]]; PRE ^ CODE [[ this is <code> tag inside <pre> ]]; }

Not yet, but I've hacked up most of the Linux sandboxing: https://github.com/256lights/zb/issues/29 I want to introduce Windows sandboxing, too, but I'm not as confident about how to do that: https://github.com/256lights/zb/issues/31

Nice! It might be a little too rough until I've got a working C compiler for Windows: https://github.com/256lights/zb/issues/6 (and Linux for that matter: https://github.com/256lights/zb/issues/30)

Nix sandboxes derivation runs on Linux even without flakes, and I'm planning on implementing that, yes: https://github.com/256lights/zb/issues/29 and https://github.com/256lights/zb/issues/31 MinGW is used to build Lua using cgo. I'd like to remove that part, see https://github.com/256lights/zb/issues/28 I haven't started the userspace for Windows yet (https://github.com/256lights/zb/issues/6), but I suspect that it will be more "download the Visual C++ compiler binary from this URL" than the Linux source bootstrap. Yeah, I'm happy with live-bootstrap, too! I tried emulating Guix's bootstrap, but it depended a little too much on Scheme for me to use as-is. live-bootstrap has mostly worked out-of-the-box, which was a great validation test for this approach.

Tracking issue is https://github.com/256lights/zb/issues/2 The hurdles to interop I see are: - Nixpkgs is not content-addressed (yet). I made a conscious decision to only support content-addressed derivations in zb to simplify the build model and provide easier-to-understand guarantees to users. As a result, the store paths are different (/zb/store instead of /nix/store). Which leads to... - Nix store objects have no notion of cross-store references. I am not sure how many assumptions are made on this in the codebases, but it seems gnarly in general. (e.g. how would GC work, how do you download the closure of a cross-store object, etc.) - In order to obtain Nixpkgs derivations, you need to run a Nix evaluator, which means you still need Nix installed. I'm not sure of a way around this, and seems like it would be a hassle for users. I have

Yup, that was how I built the prototype: https://www.zombiezen.com/blog/2024/06/zb-build-system-proto... The last commit using that approach was https://github.com/256lights/zb/tree/558c6f52b7ef915428c9af9... if you want to try it out. And actually, I haven't touched the Lua frontend much since I swapped out the backend: the .drv files it writes are the same. The motivation behind replacing the backend was content-addressibility and Windows support, which have been slow to be adopted in Nix core.

(Hi! I recognize your name from Bazel mailing lists but I forget whether we've talked before.) I'm mostly contrasting from Nix, which has difficulty with poisoning cache when faced with non-deterministic build steps when using input-addressing (the default mode). If zb encounters a build target with multiple cached outputs for the same inputs, it rebuilds and then relies on content-addressing to obtain build outputs for subsequent steps if possible. (I have an open issue for marking a target as intentionally non-deterministic and always triggering this re-run behavior: https://github.com/256lights/zb/issues/33) I'll admit I haven't done my research into how Bazel handles non-determinism, especially nowadays, so I can't remark there. I know from my Google days that even writing genrules you had to be careful about introducing non-determini