Nixpkgs config, for defining things like which licenses are
permitted, can either be an attrset or a function that is passed a
`pkgs` argument. Evaluating that `pkgs` argument requires computing the
Nixpkgs fixpoint, which requires checking whether the derivations used
in the Nixpkgs bootstrap have valid licenses. This works provided
nothing tries to use Nixpkgs functions to validate or merge anything
included in the configuration.
f5deefd463 (config: add and document {allow,block}listedLicenses,
2025-08-31), in #437723, added type checking and merging to the lists of
permitted/forbidden licenses. That resulted in a recursion loop if a
list of licenses included, say, `pkgs.lib.licenses.bsd0`.
To allow licenses to be specified from Nixpkgs' library, pass `lib` as
well as `pkgs` to any config function. Computing `lib` doesn't require
working out the full Nixpkgs fixpoint. The change in #437723 will still
break things for some people, but it at least provides a sensible route
to getting the config working again.
Fixes#456994.
Currently the defaultText of nixpkgs.pkgs uses the cfg variable. The search.nixos.org page is not able to resolve that variable.
Replacing "cfg" within this docs text with the non-aliased "config.nixpkgs".
The description for options.nixpkgs.system already hints at this:
Neither ${opt.system} nor any other option in nixpkgs.* is meant
to be read by modules and configurations.
Use pkgs.stdenv.hostPlatform instead.
We can support this goal by not elaborating the systems anymore, forcing
users to go via pkgs.stdenv.
This will prevent problems when making the top-level package sets
composable in the next commit. For this to work, you should pass a fully
elaborated system to nixpkgs' localSystem or crossSystem options.
Passing the elaborated system defeats what pkgs/top-level/default.nix
tries to do: Pass only the original args and let defaults be inferred.
The underlying problem is that lib.systems.elaborate can not deal with
arbitrary overrides, but will often return an inconsistent system
description when partially overriding some values. This becomes most
prominent if trying to override an already elaborated system.
After final improvements to the official formatter implementation,
this commit now performs the first treewide reformat of Nix files using it.
This is part of the implementation of RFC 166.
Only "inactive" files are reformatted, meaning only files that
aren't being touched by any PR with activity in the past 2 months.
This is to avoid conflicts for PRs that might soon be merged.
Later we can do a full treewide reformat to get the rest,
which should not cause as many conflicts.
A CI check has already been running for some time to ensure that new and
already-formatted files are formatted, so the files being reformatted here
should also stay formatted.
This commit was automatically created and can be verified using
nix-build https://github.com/infinisil/treewide-nixpkgs-reformat-script/archive/a08b3a4d199c6124ac5b36a889d9099b4383463f.tar.gz \
--argstr baseRev b32a094368
result/bin/apply-formatting $NIXPKGS_PATH
The assertion message should include the `nixpkgs.config` value, however
it currently includes the entire `nixpkgs.config` _option_.
This means the type, declarations, definitions, etc were all printed.
these changes were generated with nixq 0.0.2, by running
nixq ">> lib.mdDoc[remove] Argument[keep]" --batchmode nixos/**.nix
nixq ">> mdDoc[remove] Argument[keep]" --batchmode nixos/**.nix
nixq ">> Inherit >> mdDoc[remove]" --batchmode nixos/**.nix
two mentions of the mdDoc function remain in nixos/, both of which
are inside of comments.
Since lib.mdDoc is already defined as just id, this commit is a no-op as
far as Nix (and the built manual) is concerned.
Since the output of `lib.systems.elaborate` contains functions, an
equality check with `==` does not suffice, `lib.systems.equals` should
be used instead.
markdown can't represent the difference without another extension and
both the html manual and the manpage render them the same, so keeping the
distinction is not very useful on its own. with the distinction removed
we can automatically convert many options that use <code> tags to markdown.
the manpage remains unchanged, html manual does not render
differently (but class names on code tags do change from "code" to "literal").
The ${opt.*} syntax will print the full path when NixOS is used
as a submodule.
nixpkgs.system / nixpkgs.localSystem must not be read by any
other module because its meaning is ambiguous in cross vs
non-cross contexts. hostPlatform is generally what you need.
*Where* you build something generally doesn't matter in a
system _configuration_ context like NixOS.
- initialSystem was keeping track of the evaluating system
- it had been used by `nesting.children`
- since, 20.09, `nesting.children` has been replaced with named
specializations
It appears that this option was left over and not cleand up properly.
most modules can be evaluated for their documentation in a very
restricted environment that doesn't include all of nixpkgs. this
evaluation can then be cached and reused for subsequent builds, merging
only documentation that has changed into the cached set. since nixos
ships with a large number of modules of which only a few are used in any
given config this can save evaluation a huge percentage of nixos
options available in any given config.
in tests of this caching, despite having to copy most of nixos/, saves
about 80% of the time needed to build the system manual, or about two
second on the machine used for testing. build time for a full system
config shrank from 9.4s to 7.4s, while turning documentation off
entirely shortened the build to 7.1s.
* nixos/nixpkgs.nix: Allow just using config in system
This assertion requires system to work properly. We might not have
this in cases where the user just sets config and wants Nixpkgs to
infer system from that. This adds a default for when this happens,
using doubleFromSystem.
* parens
This avoids a possible surprise if the user is using `nixpkgs.system`
and `nesting.children`. `nesting.children` is expected to ignore all
parent configuration so we shouldn't propagate the user-facing option
`nixpkgs.system`. To avoid doing so, we introduce a new internal
option for holding the value passed to eval-config.nix, and use that
when recursing for nesting.
Using "builtins.currentSystem" doesn't work in pure evaluation mode,
and even when it's explicitly set (which it always is, in
nixos/lib/eval-config.nix), it breaks manual generation because the
manual tries to render the default value.
I was pointed towards a small syntax error in the `nixpkgs.overlays`
documentation. There was a trailing semicolon after the overlay
function.
I also aligned the code a bit better so opening and closing brackets can
be visually matched much better (IMO).
