Home • Explore • Blog • Models • CI
☰



nixpkgs
2nd chunk of `nixos/modules/system/service/README.md`
2b57aa5d294bcb43bcc590b741b743899d259023decec08000000001000008f7
- **`path` attribute**: Each `configData` entry automatically gets a `path` attribute set by the service manager implementation, allowing services to reference the location of their configuration files. These paths themselves are not subject to change from generation to generation; only their contents are.

- **`name` attribute**: In `environment.etc` this would be `target` but that's confusing, especially for symlinks, as it's not the symlink's target.

### Service Manager Integration

- **Portable base**: The `configData` interface is declared in `portable/config-data.nix`, making it available to all service manager implementations.

- **Systemd integration**: The systemd implementation (`systemd/system.nix`) maps `configData` entries to `environment.etc` entries under `/etc/system-services/`.

- **Path computation**: `systemd/config-data-path.nix` recursively computes unique paths for services and sub-services (e.g., `/etc/system-services/webserver/` vs `/etc/system-services/webserver-api/`).
  Fun fact: for the module system it is a completely normal module, despite its recursive definition.
  If we parameterize `/etc/system-services`, it will have to become an `importApply` style module nonetheless (function returning module).

- **Simple attribute structure**: Unlike `environment.etc`, `configData` uses a simpler structure with just `enable`, `name`, `text`, `source`, and `path` attributes. Complex ownership options were omitted for simplicity and portability.
  Per-service user creation is still TBD.

## No `pkgs` module argument

The modular service infrastructure avoids exposing `pkgs` as a module argument to service modules. Instead, derivations and builder functions are provided through lexical closure, making dependency relationships explicit and avoiding uncertainty about where dependencies come from.

### Benefits

- **Explicit dependencies**: Services declare what they need rather than implicitly depending on `pkgs`
- **No interference**: Service modules can be reused in different contexts without assuming a specific `pkgs` instance. An unexpected `pkgs` version is not a failure mode anymore.
- **Clarity**: With fewer ways to do things, there's no ambiguity about where dependencies come from (from the module, not the OS or service manager)
Title: NixOS Modular Services: `configData` Integration and 'No `pkgs` Argument' Design
Summary
This chunk elaborates on the `configData` mechanism in NixOS modular services, explaining its `path` and `name` attributes, its portable base (`portable/config-data.nix`), and its integration with Systemd where entries are mapped to `/etc/system-services/`. It also highlights the simpler attribute structure of `configData` compared to `environment.etc`. A key design decision discussed is the avoidance of `pkgs` as a module argument for service modules, promoting explicit dependency declarations, preventing interference, and enhancing clarity regarding dependency origins.