Glossary

Den introduces several domain-specific terms. This glossary defines them in Den’s context.

aspect

A composable attrset containing per-class modules (nixos, homeManager, darwin, etc.), an includes list, and nested aspects (den.aspects.<aspect>.<name>). Aspects are the primary organizational unit in Den — each one groups related configuration across multiple module systems under a single name.

See: Aspects

battery

A reusable aspect provider shipped with Den under den.batteries (aliased den.provides and den._). Batteries solve common configuration tasks like user creation, hostname setting, and home environment integration.

See: Batteries

class

A Nix module evaluation domain — nixos, darwin, homeManager, hjem, maid, user, os, or any custom class. Classes determine which module system evaluates the config. Not the same as entity kind.

See: Aspects

context

The pipeline data shape ({ host }, { host, user }, { home }) flowing through the resolution pipeline. Den context is a real function argument carrying entity references, not NixOS module arguments ({ config, pkgs, lib, ... }) and not _module.args.

See: Context pipeline

deferredModule

A NixOS module system concept — a module whose evaluation is delayed until the target configuration is assembled. Schema entries and resolved aspects are deferredModules.

See: NixOS module system

entity

A typed data declaration — a host, user, or home. Entities carry metadata (name, system, class) and freeform attributes accessible to aspects and policy resolve functions.

See: Entities

entity kind

The type of an entity: host, user, or home (or custom kinds via den.schema). Entity kinds drive policy dispatch. Not the same as class.

See: Entities

freeform

Attributes on an entity that have no declared option — arbitrary key-value data accessible via context. Freeform attributes let entities carry ad-hoc metadata without schema changes.

See: Entities

includes

A list of aspect references on an aspect or stage. Declares dependencies — “this aspect needs these other aspects to be resolved alongside it.” The full set of includes forms a DAG.

See: Aspects

parametric

A context-aware function whose argument shape determines when it applies: { host }: ... runs only in host contexts, { host, user }: ... only in user contexts. Den introspects function arguments and dispatches automatically — bare functions in includes work without any wrapper. The explicit den.lib.parametric wrapper is deprecated; the pipeline handles dispatch automatically.

See: Parametric aspects

policy

A context-driven function that declares a directed edge between entity kinds. A policy takes a context ({ host, ... }, { host, user, ... }, etc.) and returns a list of effects (includes, routes, provides); it fires when its argument signature is satisfied by the scope context. Policies are about entity topology, not stages.

See: Policies

provides

Overloaded term with two distinct meanings. On an aspect, provides (aliased _) is the legacy namespace for nested aspects, still required for the cross-entity keys to-users, to-hosts, and <host> on a user aspect; other nested aspects are written directly. At the top level, den.provides is an alias for den.batteries, the reusable aspect providers shipped with Den.

See: Aspects, Batteries

provider

An aspect intended for reuse via includes. den.batteries.* (batteries) are the built-in providers, but any aspect can serve as a provider.

See: Batteries

resolution

The process of walking an entity’s aspect graph, applying parametric dispatch, collecting per-class modules, and producing a final NixOS/HM/Darwin module. Driven by the fx pipeline.

See: Context pipeline