Pimp My IDE / Garage Dispatch
Back to garage
September 22, 2026 | build systems / dynamic graphs / evidence

Your dry run can only show the road already built.

Dynamic derivations let a Nix build discover more build steps while it runs. That opens useful routes. It also means the first plan is no longer the whole plan.

THE TAKE: When execution can write more execution, save two receipts. Keep the graph known before the run. Then record the graph discovered during the run, the inputs that selected it, and whether a matched replay resolves the same route.
Switch on the Build Graph Fog Lamp

A build plan can now write its next page.

Farid Zakaria's experiment uses Nix dynamic derivations to build a chain whose next step depends on the previous step's output. A die roll decides whether the chain stops or emits another derivation. Only the first box exists when evaluation begins. The later boxes are written by builders while the build is underway.[1]

The dice are a teaching device, not a build recommendation. The useful part is the change in scheduling. The complete graph does not need to exist before execution starts.

That changes what "dry run" can promise.

A conventional build graph supports a strong preview. Tools can inspect dependencies, compare closures, and estimate work before builders run. If a step emits another derivation, the initial preview can show the producer but not the full graph produced from its result.

Unknown is not nondeterministic. It means the answer arrives later.

Keep those terms separate. A dynamic graph may resolve to the same graph for the same inputs every time. A fully known graph can still contain an impure step. Nix documents dynamic derivations and impure derivations as separate experimental features. The first permits derivation outputs to introduce more derivations. The second permits differing outputs and network access.[2]

Randomness makes a good flare and a bad default.

The Reproducible Builds project gives the plain rule: random data makes builds unreproducible. If a tool needs random-like input, use a predetermined seed from a recorded source.[3]

For a dynamic build, record the values that choose the next branch. Save the emitted derivations or an equivalent resolved graph. Then replay from the same inputs and compare the result. You are not trying to force every build into a static plan. You are making late discovery inspectable.

Review the graph in two exposures.

  1. Capture the graph visible before any builder runs.
  2. Pin every input that can select a later branch.
  3. Log each newly emitted derivation with its parent and output.
  4. Save the final resolved graph beside the build result.
  5. Replay once with matched inputs and compare graph and output hashes.

Do not label this proof of safety. A repeated route can repeat a bad action. The two exposures answer a narrower question: what work was planned, what work appeared later, and can another operator reproduce that route?

Interactive makeover / temporal graph inspector

Build Graph Fog Lamp.

Traditional purpose replaced: one static dependency graph and a green build badge. Better version: compare known-up-front and discovered-during-run routes, scrub the discovery clock, close four evidence circuits, and copy the resulting replay plan.

Drive the graph through the fog

Choose the scheduling model, then move through the discovery stages. Blue means the node was visible before execution, not that its work is complete. Amber nodes appeared only after a parent produced them.

Graph model
0 / initial plan4 / graph resolved
PLANinput
FETCHstep 1
COMPILEstep 2
PACKAGEstep 3
CHECKstep 4
known early, not completeddiscovered during executionnot visible yet
Evidence circuits
PLAN VISIBLE1 / 4 circuits
The route is visible before ignition.

This static model exposes every node before the first builder runs. The evidence circuits still determine whether the finished route can be handed off.

Why it is better: the native controls drive the graph, lamp, status, and handoff card together. Unknown future work stays visible as unknown instead of hiding behind a final pass badge.
Sources read, not vibes
  1. Farid Zakaria, "A build graph that rolls dice": dynamic derivations, the applicative/monadic distinction, evaluator versus scheduler binding, and the random chain demonstration.
  2. Nix 2.32.9 reference manual, experimental features: current definitions and status of dynamic derivations and impure derivations. The manual says experimental features can change or be removed.
  3. Reproducible Builds, "Randomness": avoid random build input or use a predetermined seed from a recorded source.
  4. Hacker News discussion, September 20, 2026: exact discovery thread for Zakaria's article. It is not evidence for the technical claims above.

Source boundary: Zakaria's article is an exploratory demonstration. The Nix manual defines the current experimental interfaces. Reproducible Builds supplies general deterministic-build guidance. The two-exposure review method and Fog Lamp are Pimp My IDE's proposed practice, not a reported Nix benchmark or safety result.