Conversation
… uniform names
The flake-parts integration used to export its functions flat under
lib.caisson (mkFlake, mkFlakeModule, types) while the other integrations
each had a namespace, and every integration named its entry points
differently (mkSystem, mkHomeConfiguration, mkColmenaHive,
mkSystemConfig, mkTerranixConfiguration). Every integration now lives at
lib.caisson.<target> and exports the same two names: mkModule (the
class-bound caisson-core.mkModule) and mkConfiguration (evaluate the
target's module system with the selected class modules). Variants keep
the suffix (mkConfigurationFull, mkConfigurationMinimal); target-specific
helpers (the home-manager adapters, mkSourceMeta, assertSourceCoherence)
keep their names.
lib.caisson.mkFlake -> lib.caisson.flake-parts.mkConfiguration
lib.caisson.mkFlakeModule -> lib.caisson.flake-parts.mkModule
lib.caisson.types -> lib.caisson.flake-parts.types
lib.caisson.nixos.mkSystem{,Full,Minimal} -> lib.caisson.nixos.mkConfiguration{,Full,Minimal}
lib.caisson.nixos.mkNixosModule -> lib.caisson.nixos.mkModule
lib.caisson.home-manager.mkHomeConfiguration{,Minimal}
-> lib.caisson.home-manager.mkConfiguration{,Minimal}
lib.caisson.home-manager.mkHomeManagerModule -> lib.caisson.home-manager.mkModule
lib.caisson.colmena.mkColmenaHive -> lib.caisson.colmena.mkConfiguration
lib.caisson.colmena.mkColmenaModule -> lib.caisson.colmena.mkModule
lib.caisson.terranix.mkTerranixConfiguration -> lib.caisson.terranix.mkConfiguration
lib.caisson.terranix.mkTerranixModule -> lib.caisson.terranix.mkModule
lib.caisson.system-manager.mkSystemConfig -> lib.caisson.system-manager.mkConfiguration
lib.caisson.system-manager.mkSystemManagerModule
-> lib.caisson.system-manager.mkModule
This is a breaking change with no compatibility layer: the old names
are gone. lib.caisson.nixpkgs and the tooling (eval-weight,
mkMemoizedDerivationRead) are unchanged.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The entry points now share one contract: ecosystemSrc, configModule (the configuration's single top-level module, required), moduleImports, specialArgs, and pkgSets where the target consumes a package set (nixos, home-manager); anything else forwards to the evaluator as before. That removes the per-target spellings: colmena, terranix and system-manager took a `modules` list instead of configModule; terranix took `extraArgs` and home-manager took `extraSpecialArgs` (on mkConfiguration and mkNixosAdapter) where the others took specialArgs. The evaluators still receive their own names; the translation happens inside the integration. Breaking, with no compatibility layer: `modules`, `extraArgs` and `extraSpecialArgs` are gone from the caisson surface. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
nixos and home-manager already took pkgSets because their evaluators need a package set. The other four entry points now accept it too, optionally: it is passed through as the `pkgSets` special argument everywhere, and where the evaluator has a package-set slot of its own, pkgSets.pkgs is that slot's default (terranix `pkgs`, colmena `meta.nixpkgs`, system-manager's `nixpkgs.hostPlatform`); an explicit value wins. flake-parts only forwards it. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…vised twins Each entry point now takes exactly the caisson arguments (ecosystemSrc, configModule, moduleImports, specialArgs, pkgSets, and a target's own few: nixos `system` or `prefix`, colmena `meta` and `nodes`) and composes the evaluator's call from them. Nothing else forwards: an unknown argument is an error naming the caisson argument to use where one exists (`modules`, `pkgs`, `extraArgs`, `extraSpecialArgs`, `inputs`, ...) and pointing at the twin otherwise. That removes the ways an evaluator argument used to misbehave when handed in directly: `modules` silently overwritten, anything the minimal evaluator does not take silently dropped, `pkgs` conflicting with the framework's `nixpkgs.pkgs`, `baseModules` overwritten by mkConfigurationFull. The evaluator's full surface stays reachable on purpose through mkConfigurationUnsupervised (and mkConfigurationMinimalUnsupervised for nixos): the same arguments plus `evaluatorArgs`, merged over the composed evaluator call verbatim, last, so anything the evaluator accepts can be set or replaced there. Also: the minimal NixOS evaluator hands pkgSets.pkgs over as the `pkgs` module argument instead of defining `nixpkgs.pkgs`, which has no declaring module there; colmena takes its nodes as `nodes` and the config module becomes the hive's `defaults`; terranix requires pkgSets in the closed form (it evaluates against a package set). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The deliberate way to the evaluator's full surface is named for what it takes: `ecosystemArgs`, the arguments of the ecosystem's own evaluator, beside `ecosystemSrc`. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…y are
A colmena hive's nodes are NixOS configurations, but the integration
treated them as a module class of their own with separate package-set
plumbing, so a consumer had to mirror the nixos composition by hand
inside the hive (selection, package set, special arguments) and prove
afterwards that the two evaluations agreed.
The nixos composition now lives in one shared definition
(lib-overlays/nixos/compose.nix) that both integrations import: the
selected nixos-class modules, the hive-wide configModule and the
framework's nixpkgs.pkgs module become the hive's `defaults`, and each
`nodes.<name> = { configModule, deployment? }` adds its own module.
Colmena is handed the package set's identity (path, lib, stdenv) with
empty overlays and config, which is what it reads from meta.nixpkgs
and seeds every node with; nixpkgs only allows nixpkgs.pkgs beside
empty seeding, so the nodes then take the real instance the way every
other caisson NixOS evaluation does. A node's toplevel is therefore
the derivation lib.caisson.nixos.mkConfiguration builds from the same
modules, by construction.
The colmena module class and lib.caisson.colmena.mkModule are gone
(nothing registered under the class). meta.nixpkgs, meta.specialArgs
and their per-node forms are refused with hints; the per-node forms
remain reachable through mkConfigurationWithEcosystemArgs.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…e hive The integration no longer hands colmena a hive to evaluate. A node is lib.caisson.colmena.mkNixosConfiguration: nixos.mkConfiguration's signature and composition, plus colmena's public node modules (deploymentOptions, keyChownModule, keyServiceModule, assertionModule) from the colmena ecosystem source, so the result is an ordinary NixOS configuration that also declares `deployment` and can be the host's nixosConfigurations entry, one evaluation for nixos-rebuild and colmena apply. In this namespace `ecosystemSrc` is colmena's; nixpkgs resolves as nixos.mkConfiguration resolves it without an explicit source. The hive is a module of class `colmena` (meta: name, description, machinesFile, allowApplyAll; nodes.<name>: configurations from mkNixosConfiguration), evaluated by mkConfiguration and projected onto colmena's hive schema, the nine attributes its binary reads. The schema version is asserted against the ecosystem source's own makeHive, so a colmena revision that moves it fails at evaluation. A node that did not come from mkNixosConfiguration is refused. pkgSets on the hive only serves `colmena eval`. lib.makeHive, meta.nixpkgs, the package-set stub and the shared composition file's colmena use are gone; the ecosystem-resolution unit tests probe through the terranix adapter, which still returns its evaluator's result. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
A NixOS configuration's ecosystem source is nixpkgs; colmena's is the hive's. So mkNixosConfiguration leaves the namespace and reaches the hive module as a module argument, closed over the hive's colmena source, with nixos.mkConfiguration's signature: its `ecosystemSrc` is nixpkgs like any other NixOS evaluation. Nodes are built inside the hive module; a consumer that exports one as nixosConfigurations.<host> reads it back from hive.nodes. mkNixosConfigurationWithEcosystemArgs arrives the same way. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Every integration now lives at
lib.caisson.<target>and exports the same two names:mkModule(the class-boundcaisson-core.mkModule) andmkConfiguration(evaluate the target's module system with the selected class modules). The flake-parts integration, which used to export flat underlib.caisson, moves tolib.caisson.flake-parts.lib.caisson.mkFlakelib.caisson.flake-parts.mkConfigurationlib.caisson.mkFlakeModulelib.caisson.flake-parts.mkModulelib.caisson.typeslib.caisson.flake-parts.typeslib.caisson.nixos.mkSystem/mkSystemFull/mkSystemMinimallib.caisson.nixos.mkConfiguration/mkConfigurationFull/mkConfigurationMinimallib.caisson.nixos.mkNixosModulelib.caisson.nixos.mkModulelib.caisson.home-manager.mkHomeConfiguration/mkHomeConfigurationMinimallib.caisson.home-manager.mkConfiguration/mkConfigurationMinimallib.caisson.home-manager.mkHomeManagerModulelib.caisson.home-manager.mkModulelib.caisson.colmena.mkColmenaHive/mkColmenaModulelib.caisson.colmena.mkConfiguration/mkModulelib.caisson.terranix.mkTerranixConfiguration/mkTerranixModulelib.caisson.terranix.mkConfiguration/mkModulelib.caisson.system-manager.mkSystemConfig/mkSystemManagerModulelib.caisson.system-manager.mkConfiguration/mkModuleEvery
mkConfigurationalso takes the same arguments now:ecosystemSrc,configModule(one module, required),moduleImports,specialArgs, andpkgSetswhere the target consumes a package set (nixos, home-manager); the rest forwards to the evaluator as before. Colmena, terranix and system-manager drop theirmoduleslist, terranix dropsextraArgs, and home-manager'sextraSpecialArgs(onmkConfigurationandmkNixosAdapter) becomesspecialArgs. The evaluators still get their own names; the integration translates.Each signature is the whole surface: an entry point takes exactly its caisson arguments and composes the evaluator's call from them. Nothing else forwards; an unknown argument is an error that names the caisson argument to use where one exists. That closes the ways an evaluator argument used to misbehave when handed in directly (
modulesoverwritten,pkgsconflicting with the framework'snixpkgs.pkgs,baseModulesoverwritten bymkConfigurationFull, anything the minimal evaluator does not take dropped). The evaluator's full surface stays reachable on purpose throughmkConfigurationWithEcosystemArgs(andmkConfigurationMinimalWithEcosystemArgsfor nixos): the same arguments plusecosystemArgs, merged over the composed call verbatim, last.pkgSetsis accepted everywhere (required for nixos, home-manager and terranix; the default for colmena'smeta.nixpkgsand system-manager'snixpkgs.hostPlatform; forwarded by flake-parts). Colmena takes its nodes asnodes, with the config module as the hive'sdefaults. The minimal NixOS evaluator handspkgSets.pkgsover as thepkgsmodule argument rather than definingnixpkgs.pkgs.Colmena is regularized.
lib.caisson.colmena.mkConfigurationevaluates a hive module (classcolmena:metaandnodes) and projects it onto colmena's hive schema, the nine attributes its binary reads, asserting the schema version against the ecosystem source's ownmakeHive. The hive module receivesmkNixosConfigurationas a module argument, closed over the hive's colmena source:nixos.mkConfiguration's signature and composition (so itsecosystemSrcis nixpkgs, as for any NixOS configuration) plus colmena's public node modules (deploymentOptions,keyChownModule,keyServiceModule,assertionModule). A node is an ordinary NixOS configuration that also declaresdeployment; a consumer that exports it asnixosConfigurations.<host>reads it back fromhive.nodes, one evaluation fornixos-rebuildandcolmena apply. Colmena'smakeHiveis no longer used, and there is nometa.nixpkgs, nodefaults, and no separate package-set plumbing. Every node receives colmena'snameandnodesspecial arguments (the hive extends each node with them, a lazy fixpoint), so modules written for colmena's own evaluator work unchanged, and node names are free:meta,defaultsandnetworkare ordinary names undernodes; the only names refused are the ones colmena's--onfilter could never select (containing a comma, starting with@, or empty).Breaking, with no compatibility layer: the old names and the old argument spellings are gone.
lib.caisson.nixpkgs, the home-manager adapters and provenance helpers, and the tooling namespace are unchanged.Verified with the full
nix flake check(formatter, nix-unit, eval-weight gates, integration test flakes). The companion changes are in nix-caisson/caisson-compat and nix-caisson/nix-caisson.github.io, each on a branch namedrename/integration-surface.🤖 Generated with Claude Code