| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
This variable was removed in 2016.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 error
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |/ |
|
| |\
| |
| | |
Freeform modules
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This introduces `freeformType` as a top-level module attribute, allowing
definitions like
{
freeformType = ...;
options = ...;
config = ...;
}
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
Submodules that have a freeform type set behave as if that was the type
of the option itself (for values that don't have an option). Since the
submodules options are shown as separate entries in the manual, it makes
sense to show the freeform type as the submodule type.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| | |
This is a purely cosmetic change so it's easier to see dependencies
between variables.
|
| |\ \ |
|
| | |/
| |
| |
| | |
see https://spdx.org/licenses/BSD-Protection.html
|
| | |\
| | |
| | | |
Configuration file formats for JSON, INI, YAML and TOML
|
| | | | |
|
| | | | |
|
| |/ / |
|
| |/ |
|
| |\
| |
| | |
Add Redox OS as a target
|
| | | |
|
| | |
| |
| |
| | |
This makes the type of these functions more apparent from the name.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`toHex` converts the given positive integer to a string of the hexadecimal
representation of that integer. For example:
```
toHex 0 => "0"
toHex 16 => "10"
toHex 250 => "FA"
```
`toBase base i` converts the positive integer `i` to a list of it
digits in the given `base`. For example:
```
toBase 10 123 => [ 1 2 3 ]
toBase 2 6 => [ 1 1 0 ]
toBase 16 250 => [ 15 10 ]
```
|
| |\
| |
| | |
licenses: Make single-version-only GPL explicit
|
| | |
| |
| |
| |
| |
| | |
I commonly see people use the former when they should use the latter.
Would be also in line with the SPDX change https://www.gnu.org/licenses/identify-licenses-clearly.html
|
| |/
|
|
|
| |
If many branches are created than builtins.match stack overflows because
of a bug in libstdc++: see https://github.com/NixOS/nix/issues/2147
|
| |\
| |
| | |
libvmaf: 1.5.1 -> 1.5.2
|
| | | |
|
| | | |
|
| |\ \
| | |
| | | |
obsidian: init at 0.7.3
|
| | | | |
|
| | |/
|/| |
|
| |/ |
|
| | |
|
| | |
|
| |\ |
|
| | |
| |
| |
| | |
Note: NixOS 19.03 had Nix 2.2 and 19.09 had 2.3.
|
| |\ \
| |/
|/| |
Fix kernel configuration merge
|
| | |
| |
| |
| |
| |
| | |
Addresses https://github.com/NixOS/nixpkgs/issues/71803:
Kernel options are not merged as described, especially the "optional"
aspects. The error silences legitimate warnings.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The previous hash was too short and caused evaluation-time errors like:
invalid SRI hash 'sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA='
Additionally, since the fact that this is broken implies that nobody
could have been using it, "SRI" is a bit of a vague and obscure term,
`fakeSriHash` would be somewhat of a mouthful, and the relevant fetcher
parameters are just called `hash`, rename it to `fakeHash`.
|
| |\ \ |
|
| | | | |
|
| |/ / |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
It seems verifast was relicensed to MIT in 2016:
https://github.com/verifast/verifast/commit/b3c1bce76aec40de115c666e8d6e7d09f3f35a78
As this was the only package using lib.licenses.msrla I dropped it.
|
| |\ \
| | |
| | | |
ausweisapp2: init at 1.20.0
|
| | | | |
|
| |/ / |
|
| | | |
|