Nix Evaluation Is a Scheduling Problem

Many Nix-based utilities need a concrete list of derivations, paths, names, systems, and outputs, before they can decide what to build or deploy. Obtaining that list requires evaluating the Nix expression, which awakens thousands of lazy thunks and incurs noticeable wall-clock cost. The author notes that Nix’s built-in evaluation cache does not alleviate this problem, leading to repeated work each time a new query is issued.

Typical workarounds involve invoking nix-eval-jobs and piping its output through tools like jq to extract the needed information. While functional, this approach still suffers from gaps that are expensive to fill and forces a full re-evaluation for each invocation. The repeated parsing and loss of the graph after each run make the process inefficient for continuous integration or deployment watchers that need rapid feedback.

To address these shortcomings, the author created Evix, an async evaluation engine that talks to the stable Nix C API via custom bindings. Evix can evaluate flakes, files, or inline expressions and emits derivations as typed events, offering both a CLI replacement and, more importantly, an embeddable library API. The core concept is a long-lived Session object that streams the initial evaluation, retains the graph, and can answer subsequent queries without re-running the whole evaluation.

The Session can compute diffs, watch local inputs for changes, and operate behind a Unix socket daemon, allowing separate command invocations to share the same warm state. This design eliminates the repeated “fall of man” where each command re-creates the graph, reducing latency and providing back-pressure handling, event accumulation, and remote worker support. The daemon model also isolates processes, making it safer to embed evaluation in larger systems.

For engineers, adopting Evix means integrating a library or running its daemon instead of repeatedly calling nix-eval-jobs, which can lower CI turnaround times and simplify incremental deployment logic. The cost is the need to depend on the Evix library and its daemon infrastructure, and it may not be applicable in environments where the Nix C API cannot be linked or where existing tooling expects the exact output format of nix-eval-jobs.