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 provides sub-aspects. 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.provides (aliased 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

Dendritic

An attrset that bundles configuration across multiple Nix classes for a single concern. Named for the tree-like branching structure where one feature fans out across platforms.

See: Core principles

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 directed edge between entity kinds declaring how entities relate. Each policy has from, to, and a resolve function that fans out contexts. Policies are about entity topology, not stages.

See: Policies

provides

Overloaded term with two distinct meanings. On an aspect, provides defines named sub-aspects that dependents can include. As a battery namespace (den.provides), these are reusable aspect providers shipped with Den.

See: Aspects, Batteries

provider

An aspect intended for reuse via includes. den.provides.* (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

entity kind

A named scope in den.schema that defines a type of entity in the resolution pipeline. Entity kinds are the “where” — they define what happens at each pipeline step. Built-in kinds: host, user, home. Custom kinds are registered by adding keys to den.schema.

See: Entities