Commit Graph

164 Commits

Author SHA1 Message Date
Robert Hensing cad20d8983 lib.mkFixStrictness: Deprecate 2021-07-12 07:31:29 +02:00
Robert Hensing 99bc203025 Partially revert "lib/modules: Drop mkStrict and mkFixStrictness"
mkFixStrictness was never properly deprecated and should only be
removed after warning for some time.

This partially reverts commit 8fb9984690.
2021-07-12 07:25:52 +02:00
Janne Heß 8fb9984690
lib/modules: Drop mkStrict and mkFixStrictness
This was deprecated in 2014 and is not used anywhere in the tree.
2021-06-06 20:53:05 +02:00
Robert Hensing 0633b6aa74
Merge pull request #121870 from Pacman99/pass-specialargs
lib/modules: pass specialArgs to modules
2021-05-07 01:54:48 +02:00
Pacman99 c949e60220 lib/modules: pass specialArgs as a module argument 2021-05-06 16:04:08 -07:00
Silvan Mosberger 98c77a0b2d lib/modules: Small optimization 2021-05-06 04:59:27 +02:00
Silvan Mosberger f445acbe0a
Merge pull request #114955 from berbiche/fix/modules-imports-list
lib/modules: provide a better error message when "imports" contains a list
2021-05-05 23:20:39 +02:00
Nicolas Berbiche 810c9c6a0e
lib/modules: provide error message when imports contains a list 2021-05-05 14:15:04 -04:00
Robert Hensing a36e6760e9 Revert "lib/modules: Issue type deprecation warnings recursively"
This reverts commit 4b54aedee5.
2021-05-05 18:53:34 +02:00
Silvan Mosberger 4b54aedee5 lib/modules: Issue type deprecation warnings recursively
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
2021-05-03 22:16:02 +02:00
Alyssa Ross a8afbb45c1 treewide: use lib.warnIf where appropriate 2021-04-28 21:44:21 +00:00
Maximilian Bosch e878fc4aac
lib/modules: better error message if an attr-set of options is expected
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.
2021-03-11 14:55:56 +01:00
Silvan Mosberger 7f2fcc45f7
lib/modules: Set submodule type for renamed option sets
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.
2021-01-21 21:57:48 +01:00
Silvan Mosberger 9e6737710c Revert "Module-builtin assertions, disabling assertions and submodule assertions" 2020-12-18 16:44:37 +01:00
Silvan Mosberger a6a70d14a9
lib/modules: Prefix mkRemovedOptionModule & co. check names
To avoid name clashes

Co-authored-by: Robert Hensing <robert@roberthensing.nl>
2020-12-18 03:34:39 +01:00
Silvan Mosberger 767d80099c
lib/modules: Introduce _module.checks.*.check
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
2020-12-17 21:52:24 +01:00
Silvan Mosberger 991dfccbd1
lib/modules: _module.check should always be internal
Honestly this option should probably just be removed
2020-11-30 23:51:42 +01:00
Silvan Mosberger 8dea4df903
lib/modules: Remove _module.checks.*.triggerPath as it's not necessary
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.
2020-11-30 23:51:42 +01:00
Silvan Mosberger c9cc8969b4
lib/modules: Rename _module.assertions to _module.checks 2020-11-30 23:51:41 +01:00
Silvan Mosberger 3759a77fcd
nixos/modules: Expose the internal module in the top-level documentation 2020-11-30 23:51:23 +01:00
Silvan Mosberger 1e6a84b7af
nixos/modules: Allow options to be coerced to a string for convenience 2020-11-30 23:51:23 +01:00
Silvan Mosberger 20131348db
lib/modules: Use module-builtin assertions for mkRemovedOptionModule and co. 2020-11-30 23:51:23 +01:00
Silvan Mosberger 9523df7eb6
nixos/assertions: Use module-builtin assertion implementation 2020-11-30 23:51:22 +01:00
Silvan Mosberger df5ba82f74
lib/modules: Implement module-builtin assertions
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.
2020-11-30 23:51:19 +01:00
Silvan Mosberger e08182020c
Merge pull request #99115 from Infinisil/toString-module-files
lib/modules: Make sure to not import module _file's into the store
2020-11-30 21:00:59 +01:00
Robert Hensing 7102388834
Merge pull request #101139 from roberth/lib-use-static-scope-checking
lib: Use Nix's static scope checking, fix error message, optimize
2020-10-26 06:59:17 +01:00
Robert Helgesson e0fa72d04d
docs: update documentation of `mkRemovedOptionModule`
Since b08b0bcbbe, the function actually
causes an assertion error, not a warning.
2020-10-24 23:01:01 +02:00
Robert Hensing f8ab5fcd8d lib/modules: Simplify inherits 2020-10-22 13:46:48 +02:00
Robert Hensing afa6c51f27 lib: Use Nix's static scope checking, fix error message, optimize
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.
2020-10-22 13:46:47 +02:00
zimbatm d8e4c8e612
Merge pull request #96641 from zimbatm/data-module-imports
nixos: Data module imports
2020-10-09 17:07:51 +00:00
Silvan Mosberger 769eac0740
lib/modules: Make sure to not import module _file's into the store
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.
2020-09-29 22:47:58 +02:00
Silvan Mosberger 910dfdc41e
lib/modules: Evaluate single defs for readOnly error
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.
2020-09-21 18:24:52 +02:00
Silvan Mosberger bdfcee2590
lib/modules: Improve error messages using showDefs 2020-09-21 18:24:52 +02:00
zimbatm 035627dff2
lib: allow to import JSON and TOML files
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)
      ];
    }
2020-09-12 16:37:50 +02:00
Silvan Mosberger 1d4656225d
lib/types: Allow types to emit a deprecation warning
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
2020-09-07 13:17:14 +02:00
rnhmjoj 20d491a317
treewide: completely remove types.loaOf 2020-09-02 00:42:50 +02:00
Maximilian Bosch fa30c9abed
lib/modules: improve error-message for undeclared options if prefix contains 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'.
2020-08-18 15:25:26 +02:00
Silvan Mosberger d5700d626c
lib/modules: Fix nonexistant option error
The refactoring in fd75dc8765
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
2020-08-18 00:12:36 +02:00
Silvan Mosberger 42cf8130d7
lib/modules: Add syntactic sugar for config._module.freeformType
This introduces `freeformType` as a top-level module attribute, allowing
definitions like

  {
    freeformType = ...;
    options = ...;
    config = ...;
  }
2020-08-14 22:49:04 +02:00
Silvan Mosberger e0ded8f4ba
lib/modules: Fix freeform modules when there's no definitions 2020-08-10 17:27:33 +02:00
Silvan Mosberger 65e25deb06
lib/modules: Implement freeform modules
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.
2020-08-03 22:37:00 +02:00
Silvan Mosberger fd75dc8765
lib/modules: Internally collect all unmatched definitions
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.
2020-08-03 22:37:00 +02:00
Silvan Mosberger b02a3d7b08
lib/modules: Scope module evaluation variables more tightly
This is a purely cosmetic change so it's easier to see dependencies
between variables.
2020-08-03 22:37:00 +02:00
Silvan Mosberger 9eecf2d057
Revert "lib/modules: Throw better error when definitions assign to an option set"
This reverts commit 15c873b486.

This was causing infinite recursion when depending on nested options
2020-03-19 03:50:15 +01:00
Silvan Mosberger e931de58a2
lib/modules: Fix type checks not being done before merging
Co-Authored-By: Robert Hensing <robert@roberthensing.nl>
2020-03-18 04:38:53 +01:00
Silvan Mosberger 15c873b486
lib/modules: Throw better error when definitions assign to an option set 2020-03-18 04:38:50 +01:00
Silvan Mosberger dcdd232939
lib/modules: Remove internal _module attribute from config
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.
2020-03-17 19:19:39 +01:00
Robert Hensing 9c0ab2f26d lib/modules.nix: Add file context to unmerged values in mergeDefinitions
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!";
    }
2020-02-24 00:15:36 +01:00
Janne Heß 790cd012d0
nixos/lib: Inherit type for doRename options
Co-authored-by: Silvan Mosberger <contact@infinisil.com>
2020-01-20 22:06:20 +01:00
Silvan Mosberger 9e97e64847
lib/modules: Switch _module.args from attrsOf to lazyAttrsOf 2020-01-10 16:20:31 +01:00