Skip to content

Record how each configuration selected its modules - #127

Merged
clhodapp merged 2 commits into
mainfrom
feat/selection-record
Oct 21, 2026
Merged

clhodapp merged 2 commits into
mainfrom
feat/selection-record

Conversation

@clhodapp

@clhodapp clhodapp commented Oct 20, 2026 •

Copy link
Copy Markdown
Contributor

Builds on nix-caisson/caisson-core#52, merged. This branch pins caisson-core to main, which has it.

The manifest of each configuration now carries moduleImports, the account of its module selection that design section 5 asks for. It answers "why is this module here":

  • act: default when the configuration took the default of its class, appended when it gave extraModuleImports alone, and reset when it gave moduleImports;
  • position: the file and line number where it gave that argument;
  • default: the default in force, each entry with its registry key, the level that added it and the file that defines it;
  • selected: the registry keys of the modules it selected.

For the pinned-world machine, the account reads:

  • The top passes moduleImports = _modules: [ ], so its record is act = "reset", with tests/pinned-world/default.nix and the line number.
  • The NixOS configuration records act = "default", with modules.nixos.caisson/default from the class default.
  • The home-manager configuration inside it records the class default, then modules.homeManager.nixos-parent, added at [ { system x86_64-linux } { nixos probe } ] from modules/nixos/default/caisson.

How. mkModuleConfiguration takes selection = { class; args; }, and every integration passes its class and its arguments. The new selectionAccountOf works out the account, and the builder records it through caisson-core's recordFromEvaluation. Each forChildren.extraDefaultModuleImports addition now reaches caisson-core as { select; file; }, with the file that defines it, and caisson-core adds the level. moduleImportsOf reads select from each entry. inSource, registryPartsOf and the new registryKeyOf moved out of declarationEventsOf so both can use them.

Test. The pinned-world test selectionsRecordHowModulesWereChosen checks the three accounts above. nix flake check passes locally, including the VM tests and the evaluation-cost gate. No workspace consumer reads a manifest's defaultModuleImports, the field whose shape changed.

The docs are in nix-caisson/nix-caisson.github.io#82.

🤖 Generated with Claude Code

The manifest of each configuration now carries `moduleImports`, the
account of its module selection:

- `act`: `default` when it took the default of its class, `appended`
  when it gave `extraModuleImports` alone, and `reset` when it gave
  `moduleImports`, which replaces the default;
- `position`: the file and line number where it gave `moduleImports`
  or `extraModuleImports`;
- `default`: the default in force, each entry with its registry key,
  the level that added it (the name path of a level that gave it
  through `caisson.forChildren.extraDefaultModuleImports`) and the file
  that defines it;
- `selected`: the registry keys of the modules it selected.

`mkModuleConfiguration` takes `selection = { class; args; }` and
records the account through caisson-core's `recordFromEvaluation`, and
every integration passes its class and its arguments. A level's
additions to the default now reach caisson-core as
`{ select; file; }`, with the file that defines them, and caisson-core
adds the level. caisson is pinned to the caisson-core branch that
records them.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ns came from

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@clhodapp
clhodapp merged commit 1aed019 into main Oct 21, 2026
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant