Decide what a card shows when one file is evaluated many times #3

New issue

Open

opened 2026-09-12 02:38:51 +09:00 by natsukium · 1 comment

natsukium commented

2026-09-12 02:38:51 +09:00

Owner

A card has exactly one VALUE row, which assumes a file belongs to one
evaluation. In a real configuration it does not: in natsukium/dotfiles
modules/features/ghq.nix is evaluated in eight NixOS hosts and three Darwin
hosts, and the merged value of cfg.enable differs between them.

This is a design question, not a missing function. Two answers worth weighing:

Each page names one reference evaluation. Simple, and the document stays a
document; it silently shows one host's answer as if it were the answer.
A card shows the value per evaluation that includes the file. Honest, and it
makes the card a table — which is most of what makes a configuration hard to
read in the first place, so it may be worth it.

A decision here is a prerequisite for flake-parts support, since a flake-parts
repository is exactly the shape that produces many evaluations of one file.

A card has exactly one VALUE row, which assumes a file belongs to one evaluation. In a real configuration it does not: in natsukium/dotfiles `modules/features/ghq.nix` is evaluated in eight NixOS hosts and three Darwin hosts, and the merged value of `cfg.enable` differs between them. This is a design question, not a missing function. Two answers worth weighing: - Each page names one reference evaluation. Simple, and the document stays a document; it silently shows one host's answer as if it were the answer. - A card shows the value per evaluation that includes the file. Honest, and it makes the card a table — which is most of what makes a configuration hard to read in the first place, so it may be worth it. A decision here is a prerequisite for flake-parts support, since a flake-parts repository is exactly the shape that produces many evaluations of one file.

natsukium referenced this issue

2026-09-12 02:39:03 +09:00

Build an option index from a flake-parts evaluation #4

natsukium commented

2026-09-12 13:06:16 +09:00

Author

Owner

Decision: evaluate every configuration that includes the file, and group the card by value rather than by host.

One distinct value across the evaluations: a single VALUE row, exactly as today.
Several: one row per distinct value, each annotated with the hosts that produce it (true — 8 hosts / false — nixos-foo, darwin-bar). Rows grow with the number of distinct values, not the number of hosts, and in practice that is one or two.
definitions likewise: the union of contributing files, with host names only where they differ.
type, default and description do not vary between evaluations and stay single rows.

No reference evaluation is chosen, so no host's answer is presented as the answer, and the page stays a document rather than a table. Cost is bounded because each host's options is lazy and only indexed options are forced.

Decision: evaluate every configuration that includes the file, and group the card by value rather than by host. - One distinct value across the evaluations: a single VALUE row, exactly as today. - Several: one row per distinct value, each annotated with the hosts that produce it (`true` — 8 hosts / `false` — nixos-foo, darwin-bar). Rows grow with the number of distinct values, not the number of hosts, and in practice that is one or two. - `definitions` likewise: the union of contributing files, with host names only where they differ. - `type`, `default` and `description` do not vary between evaluations and stay single rows. No reference evaluation is chosen, so no host's answer is presented as the answer, and the page stays a document rather than a table. Cost is bounded because each host's `options` is lazy and only indexed options are forced.

natsukium referenced this issue

2026-09-12 13:06:16 +09:00

Build an option index from a flake-parts evaluation #4

natsukium referenced this issue from a commit

2026-09-15 09:41:17 +09:00

Write down the two JSON contracts between the stages