Home • Explore • Blog • Models • CI
☰



nixpkgs
3rd chunk of `doc/module-system/module-system.chapter.md`
26da82f9d87d214a16ffe8af34c760d4db79cbfd3bb0b6cf000000010000084e
So if you have a configuration that has been (or will be) largely evaluated, almost none of the computation is shared with the configuration returned by `extendModules`.

The real work of module evaluation happens while computing the values in `config` and `options`, so multiple invocations of `extendModules` have a particularly small cost, as long as only the final `config` and `options` are evaluated.

If you do reference multiple `config` (or `options`) from before and after `extendModules`, evaluation performance is the same as with multiple `evalModules` invocations, because the new modules' ability to override existing configuration fundamentally requires constructing a new `config` and `options` fixpoint.
:::

#### `_module` {#module-system-lib-evalModules-return-value-_module}

A portion of the configuration tree which is elided from `config`.

<!-- TODO: when markdown migration is complete, make _module docs visible again and reference _module docs. Maybe move those docs into this chapter? -->

#### `_type` {#module-system-lib-evalModules-return-value-_type}

A nominal type marker, always `"configuration"`.

#### `class` {#module-system-lib-evalModules-return-value-_configurationClass}

The [`class` argument](#module-system-lib-evalModules-param-class).

#### `graph` {#module-system-lib-evalModules-return-value-graph}

Represents all the modules that took part in the evaluation.
It is a list of `ModuleGraph` where `ModuleGraph` is defined as an attribute set with the following attributes:

- `key`: `string` for the purpose of module deduplication and `disabledModules`
- `file`: `string` for the purpose of error messages and warnings
- `imports`: `[ ModuleGraph ]`
- `disabled`: `bool`

## Module arguments {#module-system-module-arguments}

Module arguments are the attribute values passed to modules when they are evaluated.

They originate from these sources:
1. Built-in arguments
    - `lib`,
    - `config`,
    - `options`,
    - `_class`,
    - `_prefix`,
2. Attributes from the [`specialArgs`] argument passed to [`evalModules`] or `submoduleWith`. These are application-specific.
Title: `evalModules` Return Values (`_module`, `_type`, `class`, `graph`) and Module Arguments
Summary
This chunk first concludes the discussion on `extendModules` evaluation performance, noting that referencing `config` or `options` from different stages (before and after `extendModules`) can negate performance benefits by requiring a new fixpoint computation. It then defines additional `evalModules` return values: `_module` (an elided part of the configuration tree), `_type` (a nominal "configuration" marker), `class` (the `class` argument passed to `evalModules`), and `graph` (a list of `ModuleGraph` objects detailing modules involved in the evaluation, including `key`, `file`, `imports`, and `disabled` status). The chunk then introduces "Module arguments," which are attribute values passed to modules during evaluation, originating from built-in arguments (`lib`, `config`, `options`, `_class`, `_prefix`) and application-specific `specialArgs`.