zb is an experiment in hermetic, reproducible build systems. It is a prototype and should not be used for production purposes.
zb is based on the ideas in The purely functional software deployment model by Eelco Dolstra and Build systems à la carte, as well as the author's experience in working with build systems. The build model is the same as in Nix, but build targets are configured in Lua instead of a domain-specific language.
The hello world example:
return derivation {
name = "hello";
infile = path "hello.txt";
builder = "/bin/sh";
system = "x86_64-linux";
args = {"-c", "while read line; do echo \"$line\"; done < $infile > $out"};
}
Other examples:
- Multi-step builds
stage0-posix/x86_64-linux.lua
, which uses the stage0-posix project to build a minimal userspace (including a rudimentary C compiler).bootstrap.lua
, which follows the live-bootstrap project steps to build a more complete userspace.
- Install Nix (used as a temporary build backend, see Caveats below)
go build ./cmd/zb
./zb build --file demo/hello.lua
You can use ./zb --help
to get more information on commands.
zb uses a slightly modified version of Lua 5.4.
The primary difference is that strings
(like those returned from the path
function
or the .out
field of a derivation)
can carry dependency information,
like in the Nix expression language.
This is largely hidden from the user.
From there, the following libraries are available:
- Basic functions
- The
table
module - Additional functions, such as
path
andderivation
. These are intentionally similar to the Nix built-in functions.
- Prove that Lua is a viable alternative to a domain-specific build language. (Done!)
- Exclusively use content-addressed outputs. (Done!) This enables shallow builds, as described in Build systems à la carte.
- Establish a source bootstrap that is equivalent to the nixpkgs standard environment. (Partially implemented by following the live-bootstrap steps.)
- Permit optional interoperability with the nixpkgs ecosystem. (Not implemented yet: #2)
The following is a list of shortcuts taken for the zb prototype.
- zb requires Nix to be installed.
zb acts as a frontend over
nix-store --realise
to actually run the builds, but this dependency could be removed in the future. - zb was written in Go for speed of development. This makes self-hosting more complex, but there's nothing preventing a more production-ready implementation in C/C++.
- The Lua
next
andpairs
functions should sort keys to be deterministic. - Need to stabilize the Lua standard library that's available.
string.format
specifically would be good, but would require some fancy work to support the "context" dependency feature. - The stage0 demo is not entirely hermetic,
since it uses the host's
/bin/sh
. Hypothetically, the demo could use the included kaem shell if kaem could support$out
expansion. - The
derivation
built-in does not support theoutputs
parameter to declare multiple outputs. - In the
demo
directory, most all derivations are in a single file. A more full standard library would split up files.