kiri/lux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: move to single-user config

Browse Source
This commit is contained in:
Jelle Spreeuwenberg
2026-04-26 18:08:48 +02:00
parent 75ba00929e
commit dba24ce5f3
27 changed files with 160 additions and 300 deletions
Download Patch File Download Diff File Expand all files Collapse all files
AGENTS.md
+8 -7
View File
@@ -35,18 +35,19 @@ In this repo, `flake.nix` imports `./modules` recursively via `inputs.import-tre
- `modules/hosts/<name>/default.nix`: host features that assemble NixOS aspects into `flake.modules.nixos.<name>`.
- `modules/secrets/`: secret-related features shared by hosts.
- `modules/flake-parts.nix`: flake-parts entrypoint; defines systems, formatter, and `flake.nixosConfigurations`.
- `modules/lib.nix`: shared constructors and helpers in `config.meta.lib`, especially `mkHost` and `mkCaddyReverseProxy`.
- `modules/data.nix`: canonical shared repo data and account attrsets exposed through `meta.lib.repo` and `meta.lib.accounts`.
- `modules/features/meta.nix`: shared metadata schema for `meta.host` and `meta.user`.
- `modules/lib/`: shared schemas, constructors, and helpers exposed through `repo.helpers`, especially `mkHost` and `mkCaddyReverseProxy`.
- `modules/data.nix`: canonical shared repo data, including the single `repo.account`, machine inventory, desktop preferences, services, and theme data.
- `modules/lib/schema.nix`: shared metadata schema for `repo.*` and NixOS `meta.machine`.
## How Features Are Applied Here
- Reusable NixOS concerns are published as `flake.modules.nixos.<name>`.
- Reusable Home Manager concerns are published as `flake.modules.homeManager.<name>`.
- Hosts are aspects too. `orion`, `polaris`, and `zenith` are `nixos` aspects assembled from smaller aspects.
- Host modules should use `config.meta.lib.mkHost` to define `meta.host`, base imports, hostname, and state version.
- Per-host user declarations should stay inline under `users.<name>` using canonical accounts from `meta.lib.accounts`, so host-local defaults stay close to the host and `mkHost` can wire `meta.host` and `meta.user` into Home Manager consistently.
- Features may rely on the `meta` contract. Existing modules already read `config.meta.host`, `config.meta.user`, and `config.meta.lib`.
- `flake.nixosConfigurations` instantiates every entry in `repo.machines` with `config.repo.helpers.mkHost`.
- Hosts define machine data under `repo.machines.<name>` and host-specific NixOS composition under `flake.modules.nixos.<name>`.
- `mkHost` wires the single `repo.account` into `users.users.<name>` and `home-manager.users.<name>`.
- NixOS modules may read `config.meta.machine`; Home Manager modules should read host facts through `osConfig.meta.machine` and user facts through `config.home` or `repo.account`.
## Preferred Aspect Patterns
@@ -68,6 +69,6 @@ Use **Collector Aspect** only when composition through imports or shared library
## Practical Heuristics
- If you are about to edit a host because of a reusable concern, that concern probably wants its own feature.
- If a Home Manager module needs host or user facts, prefer reading `config.meta.host` or `config.meta.user` instead of duplicating literals.
- If a Home Manager module needs host facts, prefer `osConfig.meta.machine`; for user facts, prefer `config.home` or `repo.account` instead of duplicating literals.
- If a concern spans system and user space, keep both aspects in one feature so the behavior stays coherent.
- If imports would need to be conditional, redesign the aspect boundary instead.