Systant is a userspace controller, so it makes sense to manage it
via home-manager rather than as a system service. This allows:
- Declarative per-user configuration
- Access to user's environment, PATH, and session
- Proper handling of audio, display, and other user resources
Usage in home-manager config:
imports = [ inputs.systant.homeManagerModules.default ];
services.systant.enable = true;
services.systant.settings = { ... };
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Systant is designed as a userspace controller rather than a system
daemon, so it makes more sense to run as a user service with access
to the user's environment, PATH, and session (for audio control, etc).
Changes:
- Remove user/group options (runs as current user)
- Use systemd.user.services instead of systemd.services
- Remove hardening options (not needed and would restrict access)
- Add package to environment.systemPackages
Enable with: systemctl --user enable --now systant
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Relative paths in package.nix don't resolve correctly when
the flake is used as an input in another flake. Pass src
explicitly from the flake instead.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- nix/package.nix: two-phase build with fixed-output derivation for deps
- nix/nixos-module.nix: systemd service with systant.enable and systant.configFile
- flake.nix: expose nixosModules.default and overlays.default
Usage in NixOS config:
systant.enable = true;
systant.configFile = ./systant.toml;
When deps change, update hash: nix build .#systant 2>&1 | grep 'got:'
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
