Nix Evaluation Is a Scheduling Problem

The core issue behind Nix evaluation is a scheduling problem. Most Nix tools, when building or considering building something, need to obtain a list of derivations produced by an expression. This list includes details like attribute paths, names, systems, .drv paths, and outputs. These are crucial for CI systems and deployment tools to determine what has changed and whether the graph has altered.

However, evaluation is not a trivial one-time cost - it's a recurring issue across various components like CI systems, fleet of nixosConfigurations, watchers, daemons, and flake evaluation. Each of these ask for evaluations at different intervals and for varying reasons, causing the evaluation to become an increasingly expensive operation. The Nix evaluation cache is inadequate and does not meet the needs of efficient evaluation.

The author's solution is Evix, a library-first async Nix evaluation engine. It evaluates flakes, files, or inline expressions through the stable Nix C API, and reports derivations as typed events. It includes a CLI for replacing nix-eval-jobs in CI setups, but the main focus is the embeddable library API and Session, which is a long-lived evaluation object capable of streaming the first run, retaining the graph, answering queries, computing diffs, and watching local inputs for changes.

Evix operates on a model where a worker evaluates one attribute path at a time and returns one event. It navigates the Nix C API to find the derivation's name, target system, .drv path, and outputs. If needed, it also fetches meta and input derivations. This model is more reliable and allows for better control and understanding of the evaluation process.