about summary refs log tree commit diff
path: root/lib/modules.nix
Commit message (Collapse)AuthorAge
* lib/modules: add mkImageMediaOverrideDavid Arnold2021-08-03
| | | | | | | | | so the underlaying use case of the preceding commit is so generic, that we gain a lot in reasoning to give it an appropriate name. As the comment states: image media needs to override host config short of mkForce
* lib.mkFixStrictness: DeprecateRobert Hensing2021-07-12
|
* Partially revert "lib/modules: Drop mkStrict and mkFixStrictness"Robert Hensing2021-07-12
| | | | | | | mkFixStrictness was never properly deprecated and should only be removed after warning for some time. This partially reverts commit 8fb9984690c878fcd768e967190957441de05d11.
* lib/modules: Drop mkStrict and mkFixStrictnessJanne Heß2021-06-06
| | | | This was deprecated in 2014 and is not used anywhere in the tree.
* Merge pull request #121870 from Pacman99/pass-specialargsRobert Hensing2021-05-07
|\ | | | | lib/modules: pass specialArgs to modules
| * lib/modules: pass specialArgs as a module argumentPacman992021-05-06
| |
* | lib/modules: Small optimizationSilvan Mosberger2021-05-06
| |
* | Merge pull request #114955 from berbiche/fix/modules-imports-listSilvan Mosberger2021-05-05
|\ \ | | | | | | lib/modules: provide a better error message when "imports" contains a list
| * | lib/modules: provide error message when imports contains a listNicolas Berbiche2021-05-05
| | |
* | | Revert "lib/modules: Issue type deprecation warnings recursively"Robert Hensing2021-05-05
|/ / | | | | | | This reverts commit 4b54aedee5e05aaf2838f6d951508b83e33d2baa.
* / lib/modules: Issue type deprecation warnings recursivelySilvan Mosberger2021-05-03
|/ | | | | | | | | | | | | | Previously, an option of type attrsOf string wouldn't throw a deprecation warning, even though the string type is deprecated. This was because the deprecation warning trigger only looked at the type of the option itself, not any of its subtypes. This commit fixes this, causing each of the types deprecationMessages to trigger for the option. This relies on the subtypes mkOptionType attribute introduced in 26607a5a2e06653fec453c83d063cdfc4b59185f
* treewide: use lib.warnIf where appropriateAlyssa Ross2021-04-28
|
* lib/modules: better error message if an attr-set of options is expectedMaximilian Bosch2021-03-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I recently wrote some Nix code where I wrongly set a value to an option which wasn't an actual option, but an attr-set of options. The mistake I made can be demonstrated with an expression like this: { foo = { lib, pkgs, config, ... }: with lib; { options.foo.bar.baz = mkOption { type = types.str; }; config.foo.bar = 23; }; } While it wasn't too hard to find the cause of the mistake for me, it was necessary to have some practice in reading stack traces from the module system since the eval-error I got was not very helpful: error: --- TypeError --------------------------------------------------------- nix-build at: (323:25) in file: /nix/store/3nm31brdz95pj8gch5gms6xwqh0xx55c-source/lib/modules.nix 322| foldl' (acc: module: 323| acc // (mapAttrs (n: v: | ^ 324| (acc.${n} or []) ++ f module v value is an integer while a set was expected (use '--show-trace' to show detailed location information) I figured that such an error can be fairly confusing for someone who's new to NixOS, so I decided to catch this case in th `byName` function in `lib/modules.nix` by checking if the value to map through is an actual attr-set. If not, a different error will be thrown.
* lib/modules: Set submodule type for renamed option setsSilvan Mosberger2021-01-21
| | | | | | | | | | | | | For renames like mkAliasOptionModule [ "services" "compton" ] [ "services" "picom" ] where the target is an option set (like services.picom) instead of a single option (like services.picom.enable), previously the renamed option type was unset, leading to it being `types.unspecified`. This changes it to be `types.submodule {}` instead, which makes more sense.
* Revert "Module-builtin assertions, disabling assertions and submodule ↵Silvan Mosberger2020-12-18
| | | | assertions"
* 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>
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-07-23 05:05:28 +0000