Age | Commit message (Collapse) | Author | Files | Lines |
|
This new type has unsurprising merge behavior: Only attribute sets are
merged together (recursively), and only if they don't conflict.
This is in contrast to the existing types:
- types.attrs is problematic because later definitions completely
override attributes of earlier definitions, and it doesn't support
mkIf and co.
- types.unspecified is very similar to types.attrs, but it has smart
merging behavior that often doesn't make sense, and it doesn't support
all types
|
|
Previously it would error out for a single function definition
|
|
|
|
|
|
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)
];
}
|
|
Complements the `lib.importJSON`. `builtins.readTOML` has been
introduced in Nix 2.1.
|
|
|
|
|
|
Fix arch eval error
|
|
This occurs when using a `platform.gcc.arch` that isn't one of the
pre-existing hard-coded options.
|
|
Jasper has been marked insecure for a while, and upstream has not
been responsive to CVEs for over a year.
Fixes #55388.
Signed-off-by: David Anderson <dave@natulte.net>
|
|
cc-wrapper: Fix for prebuilt android
|
|
074bc78cc8749faa31729096b65f2ef51b10abeb evidently meant to do this, but
forgot.
|
|
* Okapi is an artiodactyl mammal native to Central Africa
* https://en.wikipedia.org/wiki/Okapi
|
|
Better type deprecation messages
|
|
Show sub options of freeform types
|
|
|
|
|
|
|
|
Has been deprecated since fd803fce606a007403ba6d05f09ed2e6a3371830
(2013-08-22)
|
|
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
|
|
|
|
Previously if you set the freeform type to e.g. attrsOf (submodule ..),
those submodule options wouldn't be shown in the manual.
|
|
> NOTE: This function is not performant and should be avoided.
It's not used at all in-tree now, so we can remove it completely after
any remaining users are given notice.
|
|
treewide: completely remove types.loaOf
|
|
platform.gcc.arch: support for AMD CPUs
|
|
|
|
|
|
Make pkgsStatic set "static" argument to true
|
|
|
|
|
|
Support Android 29 in cross-compilation
|
|
This change allows derivations to distinguish dynamic musl build and
static musl build in cases where upstream build system can't detect it
by itself.
|
|
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 = ...;
}
|
|
|
|
|
|
|
|
|
|
see https://spdx.org/licenses/BSD-Protection.html
|
|
|