[clhodapp]

A macOS machine now activates the homes and hjem configurations declared inside it, as a NixOS machine does. This PR is based on #94 (hjem). Its diff is the darwin commit alone. Merge #94 first, then change the base of this PR to main. The repository does not delete merged branches, so GitHub does not change the base by itself.

The machine of a home

A home or hjem configuration used to read its machine as nearest.nixos. The new caisson.integrations.nearestOf [ "nixos" "darwin" ] returns the nearer of the nearest NixOS configuration and the nearest darwin configuration. The nearer one is the one with more ancestors. A home inside a darwin machine gets osConfig, osClass = "darwin" and darwinConfig, as home-manager's nix-darwin module gives them, and it is published as <user>@<machine>. Only a NixOS machine gives an hjem configuration hjem's systemd.nix, because hjem's nix-darwin module does not import it. Both kinds of machine give osOptions.

caisson's default darwin module

A darwin configuration had no default module. The new one does three things:

• Through caisson.forChildren, it gives each home the home-manager module darwin-parent and each hjem configuration the hjem module darwin-parent. They set what home-manager's and hjem's nix-darwin modules set from the machine's account: the home directory, the user ID read with tryEval as home-manager reads it, and the Nix of the machine.
• It imports home-manager-activation. That module adds the postActivation step of home-manager's nix-darwin module, which runs each home's activate as its user through launchctl asuser and sudo. As in caisson's NixOS activation, activate runs without a driver version, so the user's home-manager profile keeps working with home-manager switch.
• It imports hjem-activation. That module writes the two launchd agents of hjem's nix-darwin module, org.hjem.activate and org.nix.link-nix-apps, with upstream's scripts. It also adds the users' packages and records their extraDependencies in /etc/hjem/extra-dependencies.

The hjem module differs from upstream in two places.

1. nix-darwin installs launchd.user.agents into the home of system.primaryUser alone, so upstream's agent runs for the primary user only. Upstream also requires system.primaryUser to be set. caisson declares the agents in launchd.agents, which nix-darwin installs in /Library/LaunchAgents. launchd loads agents from there for every user at login. Each agent exits for a user that no hjem configuration of the machine names.
2. nix-darwin's activation script runs a fixed list of steps (modules/system/activation-scripts.nix). Upstream restarts the activation agent from a step named hjem-activate-kick, which is not on that list, so the restart never runs. It restarts the applications agent from applications, which runs before the launchd step installs the new agents. caisson restarts both agents from postActivation, which runs after the agents are installed.

Tests

• The darwin probe declares a second machine, family, with a home and an hjem configuration for its user. The bare machine still builds exactly the derivation darwinSystem builds.
• A new pinned-world test checks four things about family:
  • Both configurations take their directory, and the home its uid, from the account.
  • postActivation runs the home's activation wrapper through launchctl asuser and restarts org.hjem.activate.
  • The agent sits in launchd.agents, and launchd.user.agents is empty.
  • The hjem manifest equals what hjem's nix-darwin module makes from the same user module, and the configurations are published as probe@family and probe.
• checks.aarch64-darwin.darwin-system now builds both systems, so the macOS job builds the home's activation package and hjem's CLI.
• A unit test covers nearestOf.

Activation on a running Mac is not tested.

Caisson's evaluation overhead in the eval-weight check is 4.18 MB, against 4.15 MB on #94, and the ceiling is 4.28 MB. All 18 workspace consumers pass nix flake check --no-build at #96, which contains this branch. That run puts the branch in place of both caisson pins of each consumer: the root input, and the tests/dependencies lock that the checks partition reads. An earlier run on this branch alone overrode only the root input, so those partitions then ran against the caisson they pin.

🤖 Generated with Claude Code