Switch the option type to `deferredModuleWith`, which collects definitions without evaluating them.
The raw definitions are forwarded to nixpkgs function via a new internal `_configDefinitions` parameter.
`apply` on the option returns `finalPkgs.config`, preserving
backwards compatibility for external readers of `config.nixpkgs.config`
We’ve never deprecated a platform in widespread use before, and it
seems prudent to warn users about the upcoming end of support so they
can plan appropriately.
I tried to make this relatively unobtrusive by taking advantage of
the import cache and offering a way to turn it off, but I anticipate
there might still be issues with e.g. `nix shell nixpkgs#…` and
spammy warnings from multiple instantiations of Nixpkgs. I’m
not sure there’s much we can do about that unless we take a
different strategy entirely; `nix shell --impure nixpkgs#…` with a
`~/.config/nixpkgs/config.nix` is about the best UX we can hope to
offer with the restrictions of flakes.
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.
Group `throwIfNot` chains with parentheses to improve readability and
hint to nixfmt the intended formatting.
This makes the result visually closer to the pre-nixfmt layout:
checked =
throwIfNot (lib.isList overlays) "The overlays argument to nixpkgs must be a list."
lib.foldr (x: throwIfNot (lib.isFunction x) "All overlays passed to nixpkgs must be functions.") (r: r) overlays
throwIfNot (lib.isList crossOverlays) "The crossOverlays argument to nixpkgs must be a list."
lib.foldr (x: throwIfNot (lib.isFunction x) "All crossOverlays passed to nixpkgs must be functions.") (r: r) crossOverlays
;
Format all Nix files using the officially approved formatter,
making the CI check introduced in the previous commit succeed:
nix-build ci -A fmt.check
This is the next step of the of the [implementation](https://github.com/NixOS/nixfmt/issues/153)
of the accepted [RFC 166](https://github.com/NixOS/rfcs/pull/166).
This commit will lead to merge conflicts for a number of PRs,
up to an estimated ~1100 (~33%) among the PRs with activity in the past 2
months, but that should be lower than what it would be without the previous
[partial treewide format](https://github.com/NixOS/nixpkgs/pull/322537).
Merge conflicts caused by this commit can now automatically be resolved while rebasing using the
[auto-rebase script](8616af08d9/maintainers/scripts/auto-rebase).
If you run into any problems regarding any of this, please reach out to the
[formatting team](https://nixos.org/community/teams/formatting/) by
pinging @NixOS/nix-formatting.
The commit to make package sets composable depends on the fact that
localSystem and crossSystem can be passed forward to lower package sets
for composition. Once we pass a fully elaborated system, this will break
down - getters like "isStatic", "isMusl" etc. will not change with the
package set anymore, but be stuck on the value passed in via those
options.
This is a limitation of lib.systems.elaborate primarily, because it
can't deal with arbitrary overrides properly.
freshBootstrapTools on darwin used to do this, although in this case it
didn't do any harm: There shouldn't be any package sets composed during
bootstrap anyway. Refactor it, to avoid throwing the assert.
The various pkgsXYZ top-level package sets did not pass localSystem /
crossSystem to lower levels, so far. This change propagates original
arguments to lower levels, which include the overrides made by an upper
package sets.
There is an extensive test-suite to test various combinations of package
sets in pkgs/test/top-level. There are a few basic promises made:
- Package sets must be idempotent. pkgsMusl.pkgsMusl === pkgsMusl.
- Once pkgsCross is used any subsequent package sets should affect the
**host platform** and not the build platform. Examples:
- pkgsMusl.pkgsCross.aarch64-multiplatform is a cross compilation from
musl to glibc/aarch64
- pkgsCross.aarch64-multiplatform.pkgsMusl is a cross compilation to
musl/aarch64
- Modifications from an earlier layer should not be lost, unless
explicitly overwritten. Examples:
- pkgsStatic.pkgsMusl should still be static.
- pkgsStatic.pkgsCross.gnu64 should be static, but with glibc instead
of musl.
Exceptions / TODOs:
- pkgsExtraHardening is currently not idempotent, because it applies the
same flags over and over again.
Supersedes #136549Resolves#114510Resolves#212494Resolves#281596
Due to Nix bug <https://github.com/NixOS/nix/issues/11503>,
`builtins.filterSource` and chroot stores interact in a confusing
and broken way that breaks `lib.fileset`. This means that uses of
the API inside Nixpkgs keep breaking the NixOS installer, blocking
the channel. The resulting error messages are inscrutable (they look
like “the installer test is trying to download `curl`…?” and
eventually bottom out in a derivation that has the wrong `outPath`
because of the chroot store causing an incorrect `lib.fileset` result).
Whenever this happens, someone (well, in practice K900 or I)
has to bisect the change that introduced it and remove the use of
`lib.fileset`. This has happened at least three times in the past
four months (I believe I might actually be missing one here, but
these are the ones I remember and could easily dig up):
* <https://github.com/NixOS/nixpkgs/pull/340046>
* <https://github.com/NixOS/nixpkgs/pull/352491>
* <https://github.com/NixOS/nixpkgs/pull/369459>
The options I see here are:
1. Forbid use of `lib.fileset` within Nixpkgs until the Nix bug is
fixed. This is the approach taken here. External users of Nixpkgs
can continue to use the API as normal, but using it from within
something that affects any release jobset `outPath`s will cause an
evaluation failure with a hopefully‐helpful error message.
2. Forbid `lib.fileset` and also all of the other library APIs that use
`builtins.filterSource`. I’m happy to do this, but so far none of
those have broken the installer, so I decided to start small and
worry about the others if they end up causing a problem in practice.
3. Forbid `builtins.filterSource` directly. This is hard and would
require more invasive `builtins.scopedImport` crimes to do at
evaluation time. I think this would realistically have to be done in
something like nixpkgs-vet instead and I didn’t have much luck
shoehorning a check like this into that codebase when I tried.
4. Fix the Nix bug. This would be great! But also it doesn’t seem to be
happening any time soon, it seems difficult to fix in a way that
doesn’t subtly break compatibility with the previous semantics, and
arguably the fix would need backporting all the way back to 2.3
given our minimum version policy.
5. Do nothing; have people continue to innocuously use `lib.fileset`
throughout Nixpkgs, breaking the installer whenever one of them
sneaks in to that closure, causing the channel to be blocked and
requiring expensive bisections to narrow down the inscrutable test
failure to the package using `lib.fileset`, which then needs moving
back off it. This sucks for the people who keep having to track it
down, holds back important channel bumps, and the criteria for when
it’s okay to use `lib.fileset` are not realistically possible to
teach to all contributors.
I'd be happy to work on (2) as an alternative; (3) would be difficult
and seems like overkill, (4) is not really something I trust myself
to do and wouldn’t address the immediate problem, and (5) isn’t
sustainable. I think that the current approach here is the best
trade‐off for now, as `lib.fileset` seems to be the only prominent
user of the `builtins.filterSource` API that works with full store
paths, exposing it to the Nix bug. It’s unfortunate to lose the
nice API, but since we can’t rely on it to produce correct results
and the channels keep getting blocked as a result, I don’t think
we really have an alternative right now.
This allows modules that declare their class to be checked.
While that's not most user modules, frameworks can take advantage
of this by setting declaring the module class for their users.
That way, the mistake of importing a module into the wrong hierarchy
can be reported more clearly in some cases.
This fixes both `nix-shell` failing to eval with `nixUnstable`, as well
as ofborg's failure to eval on aarch64 due to passing an "unexpected
arg" (1112e3a8c8/ofborg/src/nix.rs (L334-L340)).
This makes things a little bit more convenient. Just pass in like:
$ nix-build ’<nixpkgs>’ -A hello --argstr localSystem x86_64-linux --argstr crossSystem aarch64-linux
This patch simply introduces a plain simple NixOS module and passes
`nixpkgs.config` through it via `evalModules` (with some temporary hackery to
passthru undefined options).
crossOverlays only apply to the packages being built, not the build
packages. It is useful when you don’t care what is used to build your
packages, just what is being built. The idea relies heavily on the
cross compiling infrastructure. Using this implies that we need to
create a cross stdenv.
Among other things, this will allow *2nix tools to output plain data
while still being composable with the traditional
callPackage/.override interfaces.
The long term goal is a big replace:
{ inherit system platform; } => buildPlatform
crossSystem => hostPlatform
stdenv.cross => targetPlatform
And additionally making sure each is defined even when not cross compiling.
This commit refactors the bootstrapping code along that vision, but leaves
the old identifiers with their null semantics in place so packages can be
modernized incrementally.
This patch add a new argument to Nixpkgs default expression named "overlays".
By default, the value of the argument is either taken from the environment variable `NIXPKGS_OVERLAYS`,
or from the directory `~/.nixpkgs/overlays/`. If the environment variable does not name a valid directory
then this mechanism would fallback on the home directory. If the home directory does not exists it will
fallback on an empty list of overlays.
The overlays directory should contain the list of extra Nixpkgs stages which would be used to extend the
content of Nixpkgs, with additional set of packages. The overlays, i-e directory, files, symbolic links
are used in alphabetical order.
The simplest overlay which extends Nixpkgs with nothing looks like:
```nix
self: super: {
}
```
More refined overlays can use `super` as the basis for building new packages, and `self` as a way to query
the final result of the fix-point.
An example of overlay which extends Nixpkgs with a small set of packages can be found at:
https://github.com/nbp/nixpkgs-mozilla/blob/nixpkgs-overlay/moz-overlay.nix
To use this file, checkout the repository and add a symbolic link to
the `moz-overlay.nix` file in `~/.nixpkgs/overlays` directory.
Introduce new abstraction, `stdenv/booter.nix` for composing bootstraping
stages, and use it everywhere for consistency. See that file for more doc.
Stdenvs besides Linux and Darwin are completely refactored to utilize this.
Those two, due to their size and complexity, are minimally edited for
easier reviewing.
No hashes should be changed.
- The darwin test can now force the use of the freshly-booted darwin stdenv
- The linux test now passes enough dummy arguments
This may make debugging harder, if so, check out #20889
This makes the flow of data easier to understand. There's little downside
because the args in question are already inspected by the stdenvs.
cross-compiling in particular is simpler because we don't need to worry
about overriding the config closed over by `allPackages`.
