c57ea7c7e3
Absorb some of the paragraphs from snix/docs/src/architecture.md, as well as the blog post around the builder protocol, and extend it with a bit more context. The parts about the Evaluator are largely outdated (see the warning above in that file), and otherwise already covered. Update and restructure protocol.md to describe the goals of the builder. Change-Id: I26ed625f7b6fcfded3e65cf87b00ceb33b75f229 Reviewed-on: https://cl.snix.dev/c/snix/+/30264 Reviewed-by: edef . <edef@edef.eu> Tested-by: besadii Autosubmit: Florian Klink <flokli@flokli.de>
3.4 KiB
| title | slug | description | summary | date | lastmod | draft | weight | toc |
|---|---|---|---|---|---|---|---|---|
| Component Overview | overview | 2025-03-14T14:14:35+01:00 | 2025-03-14T14:14:35+01:00 | false | 32 | true |
This diagram gives an overview over the different crates in the repository, the different contained components and the dependencies in between them.
If you scroll further down, you find a textual description of what each component does. Check the individual documentation pages for more details.
{{< inline-svg src="crate-diagram.svg" width="800px" height="800px" class="svg-inline-custom" >}}
Castore
snix-castore is a content-addressed data storage / syncing engine.
It uses a merkle structure to store filesystem trees, as well as a chunked blob storage for individual file contents.
It is not Nix-specific.
Store
snix-store is a Nix store implementation using snix-castore for the
underlying data structure.
It only stores metadata like store path names, nar hashes, references,
signatures etc, and offloads content storage to snix-castore, by storing the
root node describing the contents.
There's also a CLI entrypoint that can be used to host a gRPC server endpoint, copy into a store, or mount a store as a FUSE/virtiofs.
Nix-Compat
nix-compat is a library providing access to various data formats, protocols
and concepts of Nix.
It does not depend on other Snix crates, making it a low-dependency crate to include in other (non-snix) projects as well.
Other snix crates are usually the primary consumers and drive new functionality in there - new formats etc. are usually "factored out into nix-compat".
Builder
The builder consumes build requests from a client, runs builds and sends logs/telemetry to the client.
By making the build protocol a standardized interface, it's possible to make the sandboxing mechanism used by the build process pluggable.
There currently exists an OCI builder, as well as gRPC server adapter and client implementations, allowing to run the builder both locally or remotely.
Eval
snix-eval is a bytecode interpreter evaluator. It knows about basic Nix
language data structures and semantics, constructs bytecode and provides a VM
executing this bytecode.
It also provides some "core" builtins, though builtins are pluggable - you can construct an evaluator and bring your own builtins.
It also defines the EvalIO trait and provides some very simple implementations
of it, which is how the evaluator does do IO.
Glue
snix-glue provides some more builtins (those interacting with the Builder and
Store mostly).
It allows keeping snix-eval relatively simple.
CLI
snix-cli is a REPL interface, constructing an Evaluator and populating it with
most builtins present in Nix. It is our main vehicle to evaluate Nixpkgs and
check for differences.
Serde
snix-serde is a crate allowing (de)-serialisation of Rust data structures
to/from Nix. It allows you to use (a subset of) Nix as a configuration language
in/for your application.
Tracing
snix-tracing contains some common tracing / logging / progress reporting code
that's used in various CLI entrypoints.
Nar-Bridge
nar-bridge provides a Nix HTTP Binary cache server endpoint (read-write),
using snix-[ca]store to store the underlying data. It allows you to host your
own binary cache that Nix can talk to.
Snixbolt
This uses snix-eval, providing a WASM bytecode explorer running in your
browser.