Tvix re-implements Nix in Rust, and its licence split is the part to read first

A rewrite with an explicit warning attached

Tvix is a new implementation of the Nix language and package manager, and the README is direct about its status.

The warning comes early and it is not hedged. Tvix is not ready for use in production, and none of the current APIs should be considered stable in any way.

That is a statement about a research and engineering project rather than a product, and the rest of the README describes the project in that light. It is developed by TVL in their monorepo, the depot, at the tvix source tree. Code reviews take place on Gerrit, and bugs are filed in their issue tracker.

The invitation is worth quoting, because it tells you what the project wants from outsiders. For more information about Tvix, feel free to reach out, and the project is interested in people who would like to help review designs, brainstorm and describe requirements that may not yet have been considered. That is a project asking for design help rather than patches, which is what you would expect from something trying to replace a C++ implementation that took years to build.

Development discussion is focused around two IRC channels, which are also available via XMPP and via Matrix. TVL runs the `#tvl` channel, and the Tvix-related discussion there is focused on eval and on almost one to one replacements of C++ Nix with Rust components. There is also a low-traffic mailing list with occasional design discussions.

There is a second warning that is administrative rather than technical, and it is worth knowing before you clone the wrong thing. Any other instances of this project or repository are mirrors, and the project does not accept code contributions or issues outside the methods outlined in the README, which are Gerrit for code and the issue tracker for bugs.

The default branch here is `canon`, and the repository description notes that this is a read-only mirror of the source at code.tvl.fyi.

Twelve components, each mirroring a piece of the original Nix

The components list is the architecture, and it maps closely onto how Nix itself is divided.

`//tvix/eval` is an implementation of the Nix programming language. `//tvix/store` is described as a filesystem linking Nix store paths and metadata with the content-addressed layer, and `//tvix/castore` is subtree storage and transfer in a content-addressed fashion. `//tvix/build` is a generic, Nix-unaware, builder protocol with various implementations.

`//tvix/glue` combines tvix-eval with the store and build components, and is the implementation of the build and import related builtins. `//tvix/cli` is a preliminary REPL and CLI implementation. `//tvix/serde` is a Rust library for using the Nix language for application configuration, which is a curious and useful direction, taking the Nix language out of its packaging context and into configuration.

Three components are about interoperability with existing Nix deployments. `//tvix/nix-compat` is a Rust library for compatibility with C++ Nix, covering features like encodings and hashing schemes and formats. `//tvix/nix-daemon` is a Nix-compatible store daemon backed by Tvix. And `//tvix/nar-bridge` is an HTTP webserver providing a Nix HTTP Binary Cache interface in front of a Tvix store, which is how a Tvix system can serve as a binary cache for a C++ Nix system.

`//tvix/tracing` is a unified library to configure logging, tracing, instrumentation and progress concerns, and `//tvix/docs` is standalone documentation.

The nar-bridge and nix-daemon components are the interesting ones for anyone thinking about a migration path, because they are the seams where a Rust implementation meets the existing ecosystem rather than trying to replace it wholesale.

The repository layout mirrors the component list, with directories for `cli/`, `eval/`, `glue/`, `nix-compat/`, `nix-compat-derive/`, `serde/` and `simstore/`, plus `nix-lang-test-suite/`, `nix-compat-derive-tests/`, `docs/`, `website/`, `nixpkgs/`, `sources/`, `scripts/` and `utils.nix`.

The Cargo workspace is a workaround, and the file says so

The root Cargo.toml is unusually talkative, and the comments in it are the most useful documentation in the repository.

The workspace exists to get a coherent set of dependencies across the Tvix crates by sharing a Cargo.lock. The file is explicit that this is necessary because of the currently limited support for Rust builds in Nix, and that it is a workaround for a technical limitation.

It is equally explicit that this does not mean `//tvix` should be considered one project. The stated aim is to remove the workspace file and make the subprojects independent.

There is a warning about the CI targets too. Targets for actual projects should not be tied to `//tvix` but to its subprojects, and a potential file at `//tvix/default.nix` should likely not expose anything other than extra steps or other auxiliary targets.

The members list shows the Rust crates that share the lock file: `cli`, `eval`, `eval/builtin-macros`, `glue`, `nix-compat`, `nix-compat-derive`, `nix-compat-derive-tests`, `serde` and `simstore`.

The shared dependency versions are visible in the workspace dependencies, and they read like a competent Rust project rather than a port of something else. `clap` for the CLI, `criterion` for benchmarking, `ed25519-dalek` for signing, `nom` for parsing, `mimalloc` for the allocator, `lexical-core` for fast float parsing, `pin-project` and `pin-project-lite`, `data-encoding` and `hex-literal` for the encodings, and `pretty_assertions` and `expect-test` for the test output.

There is a workspace clippy configuration with a single allowance, `blocks_in_conditions` set to allow because of false positives with the `#[tracing::instrument(...)]` attribute, with the upstream issue linked. That is a small but good sign, because it means the lint configuration was driven by a real problem rather than accumulated by turning warnings off one at a time.

The `crate2nix` section explains the Nix side of the Rust build. Some parts of Tvix are written in Rust, and to simplify dependency management on the Nix side they use crate2nix in a single Rust workspace in `//tvix` to maintain the Nix build configuration. When you change Cargo dependency configuration in any of the Rust projects, you run `mg run //tools:crate2nix-generate` in `//tvix` itself and commit the changes to the generated `Cargo.nix` file.

The build has three routes, and the Nix version target is fixed

Building the CLI is described with three options, and which one you use depends on how much of the TVL infrastructure you want.

The CLI can also be built with standard Rust tooling, `cargo build`, as long as you are in a shell with the right dependencies. Then there are the two Nix routes. If you cloned the full monorepo, the shell is provided by `mg shell //tvix:shell`. If you cloned the tvix workspace only, `nix-shell` provides it. And if you are in the TVL monorepo, you can also run `mg build //tvix/cli`, or `mg build` from inside that folder, for a more incremental build.

The compatibility note is the one to plan around.

We only use and test Nix builds of our software against Nix 2.3. There are a variety of bugs and subtle problems in newer Nix versions which we do not have the bandwidth to address, and builds in newer Nix versions may or may not work.

That is a real constraint, and it is a candid one. A reimplementation of a package manager that pins itself to an old release of the thing it is replacing tells you where the effort went, and it is not in chasing the moving target.

The repository also has a `buildkite.yml` for continuous integration, a `clippy.toml` for the linter configuration, and a `shell.nix` for the development shell. The `nixpkgs/` and `sources/` directories are the pinned dependencies.

The `workspace.josh` file at the root is worth noting, because it relates to the mirror warning. The README notes that other instances of this repository are `josh`-mirrors, which is why the canonical source lives at code.tvl.fyi and this GitHub repository is a read-only mirror.

The licence split lets you replace one side of a protocol

The licence structure section is short and it is the most carefully designed thing in the README.

All code implemented for Tvix is licensed under the GPL-3.0, with the exception of the protocol buffer definitions used for communication between services, which are available under a more permissive licence, MIT.

The idea behind the structure is spelled out. Any direct usage of the code, such as linking to it or embedding the evaluator, falls under the terms of the GPL3, but users are free to implement their own components speaking these protocols under the terms of the MIT licence.

That is a deliberate architecture decision expressed through licensing, and it is a good one. The protocol buffers are the seams between the components, and if those seams are MIT then someone can write their own store daemon, or their own build service, or their own client, and drop it into the architecture without becoming subject to the copyleft. The parts that constitute the implementation of Nix stay GPL, so the derivative work is protected.

For an adopter, the practical implication is that the decision is per boundary rather than per project. If you are embedding the evaluator or linking the library, the GPL3 applies. If you are writing a service that talks to a Tvix component over the defined protocols, you are not.

The rest of the repository supports the development rather than the product. There is a `nix-lang-test-suite/` directory, which is the language conformance suite, and `nix-compat-derive-tests/` for the derive macros, alongside `crate-hashes.json` for the pinned dependency hashes and the `OWNERS` file.

Editorial conclusion

Adopt Tvix if you are working on Nix itself, on the evaluator, on the store, or on the tooling around Nix, and you are prepared to follow a project whose APIs are explicitly unstable. Do not adopt it as a drop-in Nix replacement, because the README says plainly that it is not ready for production and that builds in newer Nix versions may or may not work. Verify first that the component you need is one the project actually implements, that the MIT protocol definitions cover the boundary you want to implement your own side of, and that you can follow the Gerrit review flow rather than expecting pull requests on GitHub to be accepted.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. tvlfyi/tvix on GitHub