| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
toInt and toIntBase10.
|
|
|
|
|
|
indicate a function inside an option structure
The motivation is to have a single identifier for that. Useful for the
next commit where I'll try to escape option-parts correctly (options can
be any kind of strings, but unless these are Nix identifiers, they must
be quoted).
Since `<function body>` (or `<name>`/`*`) are special identifiers in
error messages and the manual, we need a unique way to mark an option
part as function call because these are not to be quoted.
|
|
|
|
This is particularly useful for disabling modules defined in a flake.
Example:
disabledModules = [ "${flake}/modules/mymodule.nix" ];
Previously, absolute string paths were internally prepended with `modulesPath`,
which caused the module filtering to fail.
|
|
`m` must always be an attrset at this point. It is basically always
evaluated. This will make it throw when any of the attrs is accessed,
rather than just `config`. We assume that this will improve the error
message in more scenarios.
|
|
|
|
|
|
|
|
|
|
`lib.types.functionTo` type merging and docs
|
|
|
|
|
|
|
|
|
|
hercules-ci/issue-146882-transparent-submodule-options
lib.modules: Let module declare options directly in bare submodule
|
|
|
|
|
|
|
|
|
|
... where a bare submodule is an option that has a type like
`submoduleWith x`, as opposed to `attrsOf (submoduleWith x)`.
This makes migration unnecessary when introducing a freeform type
in an existing option tree.
Closes #146882
|
|
This ensures that the module file locations are propagated to the
freeform type, which makes it so that submodules in freeform types now
have their declaration location shown in the manual, fixing
https://github.com/NixOS/nixpkgs/issues/132085.
In addition, this also newly allows freeformTypes to be declared
multiple times and all declarations being merged together according to
normal option merging.
This also removes some awkwardness regarding the type of `freeformType`
|
|
This type correctly merges multiple option types together while also
annotating them with file information. In a future commit this will be
used for `_module.freeformType`
|
|
|
|
|
|
For consistency.
|
|
Strengthens the tests by making sure the whole line is matched.
|
|
Makes any programming errors more likely to show up early.
Non-obvious changes because of this:
- Ignore the `evalConfig` result in `reportFailure`; we're not checking
it at that point.
- Pre-increment `$fail` and `$pass` to make sure the arithmetic doesn't
result in a zero, which would result in a non-zero exit code for the
expression.
|
|
The exit codes aren't used for anything.
|
|
As per <https://github.com/koalaman/shellcheck/wiki/SC2124>.
|
|
|
|
The extra equal sign was confusing, and doesn't seem to be relevant.
|
|
The script uses plenty of non-POSIX features, such as referencing
`$BASH_SOURCE`.
|
|
|
|
|
|
Allows the simultaneous construction of top-level invocations and
submodule types.
This helps structure configuration systems integration code.
|
|
Previously it would give an error if there were multiple function
definitions.
|
|
This reverts commit 8b957e3b301d748e6fbbed806d82bd9d4b9d4ac4.
|
|
|
|
In 2d45a62899d47c109a0b8ce4ca9d33265b8a1a37, the submodule type
description was amended with the freeformType description. This causes
all the modules passed to the submodule to be evaluated once on their
own, without any extra definitions from the config section. This means
that the specified modules need to be valid on their own, without any
undeclared options.
This commit adds a test that evaluates a submodules option description,
which would trigger the above problem for one of the tests, if it were
not fixed by this commit as well.
This is done because the next commit makes option evaluation a bit more
strict, which would also trigger this test failure, even though it's not
related to the change at all.
|
|
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.
|
|
|
|
(cherry picked from commit 478af112e83df806bd8a51174834d2a130fbdeb9)
|
|
assertions"
|
|
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
|
|
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.
|
|
|
|
|
