doc/module-system: Adjust markdown syntax

This commit is contained in:
Robert Hensing
2025-05-09 18:39:42 +02:00
parent 5e6504c0df
commit 736327d6ca

View File

@@ -122,43 +122,39 @@ Module arguments are the attribute values passed to modules when they are evalua
They originate from these sources:
1. Built-in arguments
- `lib`,
- `config`,
- `options`,
- `_class`,
- `_prefix`,
- `lib`,
- `config`,
- `options`,
- `_class`,
- `_prefix`,
2. Attributes from the [`specialArgs`] argument passed to [`evalModules`] or `submoduleWith`. These are application-specific.
3. Attributes from the `_module.args` option value. These are application-specific and can be provided by any module.
The prior two categories are available while evaluating the `imports`, whereas
the last category is only available after the `imports` have been resolved.
### `lib` {#module-system-module-argument-lib}
[`lib`]{#module-system-module-argument-lib} [🔗](#module-system-module-argument-lib)
: A reference to the Nixpkgs library.
A reference to the Nixpkgs library.
[`config`]{#module-system-module-argument-config} [🔗](#module-system-module-argument-config)
: All option values.
Unlike the `evalModules` [`config` return attribute](#module-system-lib-evalModules-return-value-config), this includes `_module`.
### `config` {#module-system-module-argument-config}
[`options`]{#module-system-module-argument-options} [🔗](#module-system-module-argument-options)
: All evaluated option declarations.
All option values.
Unlike the `evalModules` [`config` return attribute](#module-system-lib-evalModules-return-value-config), this includes `_module`.
[`_class`]{#module-system-module-argument-_class} [🔗](#module-system-module-argument-_class)
: The [expected class](#module-system-lib-evalModules-param-class) of the loaded modules.
### `options` {#module-system-module-argument-options}
[`_prefix`]{#module-system-module-argument-_prefix} [🔗](#module-system-module-argument-_prefix)
: The location under which the module is evaluated.
This is used to improve error reporting and to find the implicit `name` module argument in submodules.
It is exposed as a module argument due to how the module system is implemented, which cannot be avoided without breaking compatibility.
All evaluated option declarations.
### `_class` {#module-system-module-argument-_class}
The [expected class](#module-system-lib-evalModules-param-class) of the loaded modules.
### `_prefix` {#module-system-module-argument-_prefix}
The location under which the module is evaluated.
This is used to improve error reporting and to find the implicit `name` module argument in submodules.
It is exposed as a module argument due to how the module system is implemented, which cannot be avoided without breaking compatibility.
It is a good practice not to rely on `_prefix`. A module should not make assumptions about its location in the configuration tree.
For example, the root of a NixOS configuration may have a non-empty prefix, for example when it is a specialisation, or when it is part of a larger, multi-host configuration such as a [NixOS test](https://nixos.org/manual/nixos/unstable/#sec-nixos-tests).
Instead of depending on `_prefix` use explicit options, whose default definitions can be provided by the module that imports them.
It is a good practice not to rely on `_prefix`. A module should not make assumptions about its location in the configuration tree.
For example, the root of a NixOS configuration may have a non-empty prefix, for example when it is a specialisation, or when it is part of a larger, multi-host configuration such as a [NixOS test](https://nixos.org/manual/nixos/unstable/#sec-nixos-tests).
Instead of depending on `_prefix` use explicit options, whose default definitions can be provided by the module that imports them.
<!-- markdown link aliases -->
[`evalModules`]: #module-system-lib-evalModules
[`specialArgs`]: #module-system-lib-evalModules-param-specialArgs