summary refs log tree commit diff
path: root/lib/modules.nix
Commit message (Collapse)AuthorAge
...
* lib/modules: Prefix mkRemovedOptionModule & co. check namesSilvan Mosberger2020-12-18
| | | | | | To avoid name clashes Co-authored-by: Robert Hensing <robert@roberthensing.nl>
* lib/modules: Introduce _module.checks.*.checkSilvan Mosberger2020-12-17
| | | | | | | | | | | | Previously the .enable option was used to encode the condition as well, which lead to some oddness: - In order to encode an assertion, one had to invert it - To disable a check, one had to mkForce it By introducing a separate .check option this is solved because: - It can be used to encode assertions - Disabling is done separately with .enable option, whose default can be overridden without a mkForce
* lib/modules: _module.check should always be internalSilvan Mosberger2020-11-30
| | | | Honestly this option should probably just be removed
* lib/modules: Remove _module.checks.*.triggerPath as it's not necessarySilvan Mosberger2020-11-30
| | | | | | Previously this option was thought to be necessary to avoid infinite recursion, but it actually isn't, since the check evaluation isn't fed back into the module fixed-point.
* lib/modules: Rename _module.assertions to _module.checksSilvan Mosberger2020-11-30
|
* nixos/modules: Expose the internal module in the top-level documentationSilvan Mosberger2020-11-30
|
* nixos/modules: Allow options to be coerced to a string for convenienceSilvan Mosberger2020-11-30
|
* lib/modules: Use module-builtin assertions for mkRemovedOptionModule and co.Silvan Mosberger2020-11-30
|
* nixos/assertions: Use module-builtin assertion implementationSilvan Mosberger2020-11-30
|
* lib/modules: Implement module-builtin assertionsSilvan Mosberger2020-11-30
| | | | | | | | | | | | | This implements assertions/warnings supported by the module system directly, instead of just being a NixOS option (see nixos/modules/misc/assertions.nix). This has the following benefits: - It allows cleanly redoing the user interface. The new implementation specifically allows disabling assertions or converting them to warnings instead. - Assertions/warnings can now be thrown easily from within submodules, which previously wasn't possible and needed workarounds.
* Merge pull request #99115 from Infinisil/toString-module-filesSilvan Mosberger2020-11-30
|\ | | | | lib/modules: Make sure to not import module _file's into the store
| * lib/modules: Make sure to not import module _file's into the storeSilvan Mosberger2020-09-29
| | | | | | | | | | | | | | | | Previously if `_file` was specified by a module: trace: warning: The type `types.string' of option `foo' defined in `/nix/store/yxhm2il5yrb92fldgriw0wyqh2kk9qyc-bug.nix' is deprecated. See https://github.com/NixOS/nixpkgs/pull/66346 for better alternative types. With this change: trace: warning: The type `types.string' of option `foo' defined in `/home/infinisil/src/nixpkgs/bug.nix' is deprecated. See https://github.com/NixOS/nixpkgs/pull/66346 for better alternative types.
* | Merge pull request #101139 from roberth/lib-use-static-scope-checkingRobert Hensing2020-10-26
|\ \ | | | | | | lib: Use Nix's static scope checking, fix error message, optimize
| * | lib/modules: Simplify inheritsRobert Hensing2020-10-22
| | |
| * | lib: Use Nix's static scope checking, fix error message, optimizeRobert Hensing2020-10-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Nix can perform static scope checking, but whenever code is inside a `with` expression, the analysis breaks down, because it can't know statically what's in the attribute set whose attributes were brought into scope. In those cases, Nix has to assume that everything works out. Except it doesnt. Removing `with` from lib/ revealed an undefined variable in an error message. If that doesn't convince you that we're better off without `with`, I can tell you that this PR results in a 3% evaluation performance improvement because Nix can look up local variables by index. This adds up with applications like the module system. Furthermore, removing `with` makes the binding site of each variable obvious, which helps with comprehension.
* | | docs: update documentation of `mkRemovedOptionModule`Robert Helgesson2020-10-24
|/ / | | | | | | | | Since b08b0bcbbec77046e5a7082177cedc12fbf1dc6c, the function actually causes an assertion error, not a warning.
* | Merge pull request #96641 from zimbatm/data-module-importszimbatm2020-10-09
|\ \ | |/ |/| nixos: Data module imports
| * lib: allow to import JSON and TOML fileszimbatm2020-09-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The vision here is that configuration tools can generate .json or .toml files, which can be plugged into an existing configuration. Eg: { lib, ... }: { imports = [ (lib.modules.importJSON ./hardware-configuration.json) ]; }
* | lib/modules: Evaluate single defs for readOnly errorSilvan Mosberger2020-09-21
| | | | | | | | | | | | If multiple definitions are passed, this evaluates them all as if they were the only one, for a better error message. In particular this won't show module-internal properties like `_type = "override"` and co.
* | lib/modules: Improve error messages using showDefsSilvan Mosberger2020-09-21
|/
* lib/types: Allow types to emit a deprecation warningSilvan Mosberger2020-09-07
| | | | | | | | | | | | Previously the only way to deprecate a type was using theType = lib.warn "deprecated" (mkOptionType ...) This caused the warning to be emitted when the type was evaluated, but the error didn't include which option actually used that type. With this commit, types can specify a deprecationMessage, which when non-null, is printed along with the option that uses the type
* treewide: completely remove types.loaOfrnhmjoj2020-09-02
|
* lib/modules: improve error-message for undeclared options if prefix contains ↵Maximilian Bosch2020-08-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | no options An easy-to-make mistake when declaring e.g. a submodule is the accidental confusion of `options` and `config`: types.submodule { config = { foo = mkOption { /* ... */ }; }; } However the error-message The option `[definition 1-entry 1].foo' defined in `<expr.nix>' does not exist. is fairly unhelpful because it seems as the options are declared at the first sight. In fact, it took a colleague and me a while to track down such a mistake a few days ago and we both agreed that this should be somehow caught to save the time we spent debugging the module in question. At first I decided to catch this error in the `submodules`-type directly by checking whether `options` is undeclared, however this becomes fairly complicated as soon as a submodule-declaration e.g. depends on existing `config`-values which would've lead to some ugly `builtins.tryExec`-heuristic. This patch now simply checks if the option's prefix has any options defined if a point in evaluation is reached where it's clear that the option in question doesn't exist. This means that this patch doesn't change the logic of the module system, it only provides a more detailed error in certain cases: The option `[definition 1-entry 1].foo' defined in `<expr.nix>' does not exist. However it seems as there are no options defined in [definition 1-entry 1]. Are you sure you've declared your options properly? This happens if you e.g. declared your options in `types.submodule' under `config' rather than `options'.
* lib/modules: Fix nonexistant option errorSilvan Mosberger2020-08-18
| | | | | | | | | | | | | | | | | | | | | | | The refactoring in https://github.com/NixOS/nixpkgs/commit/fd75dc876586bde8cdb683a6952a41132e8db166 introduced a mistake in the error message that doesn't show the full context anymore. E.g. with this module: options.foo.bar = lib.mkOption { type = lib.types.submodule { baz = 10; }; default = {}; }; You'd get the error The option `baz' defined in `/home/infinisil/src/nixpkgs/config.nix' does not exist. instead of the previous The option `foo.bar.baz' defined in `/home/infinisil/src/nixpkgs/config.nix' does not exist. This commit undoes this regression
* lib/modules: Add syntactic sugar for config._module.freeformTypeSilvan Mosberger2020-08-14
| | | | | | | | | | | This introduces `freeformType` as a top-level module attribute, allowing definitions like { freeformType = ...; options = ...; config = ...; }
* lib/modules: Fix freeform modules when there's no definitionsSilvan Mosberger2020-08-10
|
* lib/modules: Implement freeform modulesSilvan Mosberger2020-08-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For programs that have a lot of (Nix-representable) configuration options, a simple way to represent this in a NixOS module is to declare an option of a type like `attrsOf str`, representing a key-value mapping which then gets generated into a config file. However with such a type, there's no way to add type checking for only some key values. On the other end of the spectrum, one can declare a single separate option for every key value that the program supports, ending up with a module with potentially 100s of options. This has the benefit that every value gets type checked, catching mistakes at evaluation time already. However the disadvantage is that the module becomes big, becomes coupled to the program version and takes a lot of effort to write and maintain. Previously there was a middle ground between these two extremes: Declare an option of a type like `attrsOf str`, but declare additional separate options for the values you wish to have type checked, and assign their values to the `attrsOf str` option. While this works decently, it has the problem of duplicated options, since now both the additional options and the `attrsOf str` option can be used to set a key value. This leads to confusion about what should happen if both are set, which defaults should apply, and more. Now with this change, a middle ground becomes available that solves above problems: The module system now supports setting a freeform type, which gets used for all definitions that don't have an associated option. This means that you can now declare all options you wish to have type checked, while for the rest a freeform type like `attrsOf str` can be used.
* lib/modules: Internally collect all unmatched definitionsSilvan Mosberger2020-08-03
| | | | | | | | | | | | | | | | This fundamentally changes how the module evaluation internally handles definitions without an associated option. Previously the values of these definitions were discarded and only the names were propagated. This was fine because that's all that's needed for optionally checking whether all definitions have an associated option with _module.check. However with the upcoming change of supporting freeform modules, we *do* need the values of these. With this change, the module evaluation cleanly separates definitions that match an option, and ones that do not.
* lib/modules: Scope module evaluation variables more tightlySilvan Mosberger2020-08-03
| | | | | This is a purely cosmetic change so it's easier to see dependencies between variables.
* Revert "lib/modules: Throw better error when definitions assign to an option ↵Silvan Mosberger2020-03-19
| | | | | | | | set" This reverts commit 15c873b486347e7861c64fb0b5a7852be9fc82e4. This was causing infinite recursion when depending on nested options
* lib/modules: Fix type checks not being done before mergingSilvan Mosberger2020-03-18
| | | | Co-Authored-By: Robert Hensing <robert@roberthensing.nl>
* lib/modules: Throw better error when definitions assign to an option setSilvan Mosberger2020-03-18
|
* lib/modules: Remove internal _module attribute from configSilvan Mosberger2020-03-17
| | | | | | | | | | The _module option is added as an internal option set, and it messes up the results of module evaluations, requiring people to manually filter _modules out. If people depend on this, they can still use config._module from inside the modules, exposing _module as an explicitly declared user option. Or alternatively with the _module attribute now returned by evalModules.
* lib/modules.nix: Add file context to unmerged values in mergeDefinitionsRobert Hensing2020-02-24
| | | | | | | | | | | | | | | | | | | | | | | | This helps with troubleshooting exceptions in config values, which were hard to track down for options with many definitions. The trace will look like: error: while evaluating the attribute 'config.foo' at undefined position: [...] while evaluating the option `foo': [...] while evaluating definitions from `/home/user/mymod.nix': while evaluating 'dischargeProperties' at /home/user/nixpkgs/lib/modules.nix:464:25, called from /home/user/nixpkgs/lib/modules.nix:392:137: while evaluating the attribute 'value' at /home/user/nixpkgs/lib/modules.nix:277:44: Value error! where the `/home/user/mymod.nix` module is { lib, ... }: { options.foo = lib.mkOption { type = lib.types.lines; }; config.foo = builtins.throw "Value error!"; }
* nixos/lib: Inherit type for doRename optionsJanne Heß2020-01-20
| | | | Co-authored-by: Silvan Mosberger <contact@infinisil.com>
* lib/modules: Switch _module.args from attrsOf to lazyAttrsOfSilvan Mosberger2020-01-10
|
* lib/modules: Move the isDefined check into mergedValueSilvan Mosberger2020-01-10
| | | | | | | | | | | | | Without this change, accessing `mergedValue` from `mergeDefinitions` in case there are no definitions will throw an error like error: evaluation aborted with the following error message: 'This case should never happen.' This change makes it throw the appropriate error error: The option `foo' is used but not defined. This is fully backwards compatible.
* lib/modules: Fix store importsSilvan Mosberger2020-01-10
| | | | | | | | | This fixes imports from the store not being possible, which was caused by https://github.com/NixOS/nixpkgs/pull/76857 E.g. such a case: imports = [ "${home-manager}/nixos" ];
* Merge pull request #76857 from Infinisil/recursive-disableModulesSilvan Mosberger2020-01-09
|\ | | | | Apply `disabledModules` recursively
| * lib/modules: Recursive disabledModulesSilvan Mosberger2020-01-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With this change, disabledModules applies recursively, meaning if you have a module "foo.nix" with imports = [ ./bar.nix ]; then setting disabledModules = [ "foo.nix" ]; will disable both "foo.nix" and "bar.nix", whereas previously only "foo.nix" would be disabled. This change along with https://github.com/NixOS/nixpkgs/pull/61570 allows modules to be fully disabled even when they have some `mkRenamedOption` imports.
* | Clarify error message of 'assigning to top-level attribute' (#76702)Silvan Mosberger2020-01-08
|\ \ | |/ |/| Clarify error message of 'assigning to top-level attribute'
| * lib/modules: clarify error message of 'assigning to top-level attribute'Arnout Engelen2020-01-05
| | | | | | | | | | | | | | If I understand correctly, the problem isn't so much that you're assigning to that top-level attribute, but that the assignment to the attribute (or any child of the attribute) introduces the 'config' object and prevents 'lifting' all settings to a generated 'config' object.
* | lib/modules: Don't pack submodules speciallySilvan Mosberger2020-01-01
| | | | | | | | | | This has the beneficial side effect of allowing paths to be used as modules in types.{submodule,submoduleWith}
* | lib/modules: Make unifyModuleSyntax fully idempotentSilvan Mosberger2019-12-05
| | | | | | | | Because why not
* | lib/modules: file -> _file for a more idempotent unifyModuleSyntaxSilvan Mosberger2019-12-05
|/ | | | This will be useful for doing more complicated module evaluations
* Add note: Keep error message in sync with nixos-optionChuck2019-11-04
|
* Merge pull request #69746 from Infinisil/rem-opt-usage-messageSilvan Mosberger2019-10-02
|\ | | | | lib.mkRemovedOptionModule: Show replacement for option usage too
| * lib.mkRemovedOptionModule: Show replacement for option usage tooSilvan Mosberger2019-09-28
| | | | | | | | | | | | | | | | | | | | | | Previously mkRemovedOptionModule would only show the replacement instructions when the removed option was *defined*. With this change, it also does so when an option is *used*. This is essential for options that are only intended to be used such as `security.acme.directory`, whose replacement instructions would never trigger without this change because almost everybody only uses the option and isn't defining it.
* | mkRemovedOptionModule: assert on removed optionsRobin Gloster2019-09-30
|/ | | | | | | We don't want to ignore config that can mess up machines. In general this should always fail evaluation, as you think you are changing behaviour and don't, which can easily create run-time errors we can catch early.
* lib/modules: Use options `apply` function even if no values are definedSilvan Mosberger2019-08-10
| | | | | | This allows `apply` functions to return a valid value if they completely ignore their argument, which is the case for the option renaming functions like `mkAliasOptionModule`. Therefore this solves issue #63693
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-06-14 15:27:28 +0000