Hand the archetype's exported modules to profile modules, so a profile can compose one #138

New issue

Closed

opened 2026-10-07 05:07:59 +01:00 by vnprc-agent · 1 comment

vnprc-agent commented

2026-10-07 05:07:59 +01:00

A profile definition cannot currently compose a module this framework exports, which blocks any profile that needs one — the forge profile is the first. Hand the archetype's exported modules to profile modules through specialArgs, the same way mkHypervisor already hands them agenix.

Primary goals:

Exported modules reach profile modules — the service builder passes the framework's nixosModules attrset into specialArgs, so a profile module written as { allodModules, ... }: { imports = [ allodModules.forgejo ]; ... } composes it with no new flake input.
One definition of the module set — the attrset moves to nix/exported-modules.nix, consumed by both flake.nix (for the nixosModules output, unchanged for every existing consumer) and the builder, so the two cannot drift.
Not a builder argument — deliberately specialArgs and a shared file rather than a new builder parameter, because a new parameter is also a key the profiles layer can set and would have to be pinned back in nix/builder-arguments.nix.
A check witnesses the seam — an eval check drives builders.service with a fixture definition that imports a module through allodModules and asserts the composed result, so the seam is exercised rather than assumed.

Current state and specifics

allod/profiles declares exactly one input, nixpkgs, and its flake.nix header states it never grows one on secrets or inventory; an archetypes input would be an outright cycle, since archetypes consumes profiles. So profileDefinitions.service.forge has no way to name nixosModules.forgejo.

The precedent is nix/builders/hypervisor.nix, whose specialArgs already carries agenix for exactly this reason, and whose nexus profile comment refers to nexus.nixosModules.remoteAdmin.

nixosModules is currently defined inline in flake.nix (publicHost, rentedKvmGuest, staticSite, forgejo).

Scope

In: nix/exported-modules.nix, the specialArgs addition on the service builder, the check, and the README's Exports section. Out: extending the seam to the dev, privacy and hypervisor builders, which is a one-line addition per builder once a profile there needs it and should not be done speculatively; and the forge profile itself (allod/profiles).

Part of allod/strategy#65

A profile definition cannot currently compose a module this framework exports, which blocks any profile that needs one — the `forge` profile is the first. Hand the archetype's exported modules to profile modules through `specialArgs`, the same way `mkHypervisor` already hands them `agenix`. Primary goals: - **Exported modules reach profile modules** — the `service` builder passes the framework's `nixosModules` attrset into `specialArgs`, so a profile module written as `{ allodModules, ... }: { imports = [ allodModules.forgejo ]; ... }` composes it with no new flake input. - **One definition of the module set** — the attrset moves to `nix/exported-modules.nix`, consumed by both `flake.nix` (for the `nixosModules` output, unchanged for every existing consumer) and the builder, so the two cannot drift. - **Not a builder argument** — deliberately `specialArgs` and a shared file rather than a new builder parameter, because a new parameter is also a key the profiles layer can set and would have to be pinned back in `nix/builder-arguments.nix`. - **A check witnesses the seam** — an eval check drives `builders.service` with a fixture definition that imports a module through `allodModules` and asserts the composed result, so the seam is exercised rather than assumed. ### Current state and specifics `allod/profiles` declares exactly one input, `nixpkgs`, and its `flake.nix` header states it never grows one on `secrets` or `inventory`; an `archetypes` input would be an outright cycle, since `archetypes` consumes `profiles`. So `profileDefinitions.service.forge` has no way to name `nixosModules.forgejo`. The precedent is `nix/builders/hypervisor.nix`, whose `specialArgs` already carries `agenix` for exactly this reason, and whose `nexus` profile comment refers to `nexus.nixosModules.remoteAdmin`. `nixosModules` is currently defined inline in `flake.nix` (`publicHost`, `rentedKvmGuest`, `staticSite`, `forgejo`). ### Scope In: `nix/exported-modules.nix`, the `specialArgs` addition on the `service` builder, the check, and the README's Exports section. Out: extending the seam to the `dev`, `privacy` and `hypervisor` builders, which is a one-line addition per builder once a profile there needs it and should not be done speculatively; and the `forge` profile itself (`allod/profiles`). Part of allod/strategy#65

vnprc-agent referenced this issue from allod/strategy

2026-10-07 05:08:19 +01:00

A Forgejo VM on the hypervisor: PRs and issues for a forge-less deployment #65

vnprc-agent referenced this issue from a commit

2026-10-07 05:09:07 +01:00

forge VM: slice 3 issues filed, scope cut to four

vnprc-agent referenced this issue from allod/strategy

2026-10-07 17:34:28 +01:00

Define the managed service machine architecture #45

vnprc referenced this issue from a commit

2026-10-07 18:28:29 +01:00

Hand the service builder's exported modules and guest address to profile modules

vnprc-agent commented

2026-10-09 05:14:08 +01:00

Author

Landed on master in 6fac2eb (Hand the service builder exported modules and guest address to profile modules); the forge profile composes nixosModules.forgejo through allodModules on allod/profiles master. Closing as part of allod/strategy#65 housekeeping.

Landed on master in 6fac2eb (Hand the service builder exported modules and guest address to profile modules); the forge profile composes nixosModules.forgejo through allodModules on allod/profiles master. Closing as part of allod/strategy#65 housekeeping.

vnprc-agent closed this issue

2026-10-09 05:14:08 +01:00

vnprc-agent referenced this issue from allod/strategy

2026-10-09 05:14:20 +01:00

A Forgejo VM on the hypervisor: PRs and issues for a forge-less deployment #65