* 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).
Take two of #40708 (4fe2898608).
That PR attempted to bidirectionally default `config.nixpkgs.system` and
`config.nixpkgs.localSystem.system` to each be updated by the other. But
this is not possible with the way the module system works. Divergence in
certain cases in inevitable.
This PR is more conservative and just has `system` default `localSystem`
and `localSystem` make the final call as-is. This solves a number of
issues.
- `localSystem` completely overrides `system`, just like with nixpkgs
proper. There is no need to specify `localSystem.system` to clobber the
old system.
- `config.nixpkgs.localSystem` is exactly what is passed to nixpkgs. No
spooky steps.
- `config.nixpkgs.localSystem` is elaborated just as nixpkgs would so
that all attributes are available, not just the ones the user
specified.
The remaining issue is just that `config.nixpkgs.system` doesn't update
based on `config.nixpkgs.localSystem.system`. It should never be
referred to lest it is a bogus stale value because
`config.nixpkgs.localSystem` overwrites it.
Fixes#46320
My c6f7d43678 made the mistake of not
having enough defaults. Now both variables are default as the *explicit*
value of the other, or a fallback. The fallback of `system` is the
default of `localSystem.system`. The fallback of `localSystem` is not
the other default (projected), as that would cause a cycle, but `{
system = builtins.currentTime; }` just as nixpkgs itself does it.
- `localSystem` is added, it strictly supercedes system
- `crossSystem`'s description mentions `localSystem` (and vice versa).
- No more weird special casing I don't even understand
TEMP
Among other things, this will allow *2nix tools to output plain data
while still being composable with the traditional
callPackage/.override interfaces.
This can be disabled with the `withKerberos` flag if desired.
Make the relevant assertions lazy,
so that if an overlay is used to set kerberos to null,
a later override can explicitly set `withKerberos` to false.
Don't build with GSSAPI by default;
the patchset is large and a bit hairy,
and it is reasonable to follow upstream who has not merged it
in not enabling it by default.
This can be disabled with the `withKerberos` flag if desired.
Make the relevant assertions lazy,
so that if an overlay is used to set kerberos to null,
a later override can explicitly set `withKerberos` to false.
Don't build with GSSAPI by default;
the patchset is large and a bit hairy,
and it is reasonable to follow upstream who has not merged it
in not enabling it by default.
Using pkgs.lib on the spine of module evaluation is problematic
because the pkgs argument depends on the result of module
evaluation. To prevent an infinite recursion, pkgs and some of the
modules are evaluated twice, which is inefficient. Using ‘with lib’
prevents this problem.
