It may be cheaper to evaluate `(version-info.toml).nixpkgs_rev` instead
of `(nixpkgs.nix).rev` in some scenarios.
I've seen some reports of `builtins.fetchTree` _eagerly_ fetching the
FOD even without forcing `outPath`.
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.
f5deefd4631e (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 https://github.com/NixOS/nixpkgs/issues/456994.
Cherry-picks https://github.com/NixOS/nixpkgs/commit/8e94561d62272983c93f6c635919874f8d19d8f9
Inspired by https://github.com/NixOS/nixpkgs/issues/197325 this adds a
new option `nixpkgs.allowUnfreePackages`, which merges additively and can
thus be defined in multiple modules close to where the unfree package is
installed.
I would have liked to name this option
`nixpkgs.config.allowUnfreePackages`, to define it closer to where the
`allowUnfree` and `allowUnfreePredicate` are defined, but I didn't see how
this could be achieved. I would welcome some guidance on how to do this.
Cherry-picks https://github.com/NixOS/nixpkgs/commit/a3c9221d642da4c0b22b9c9576bd2af8dcbb8263
Currently, `nixpkgs.source` can be affected by flake input following.
Nixvim is sensitive to the pinned Nixpkgs revision and users often
follow inputs without thinking too much about it, so warn when this is
detected.
Expose our locked nixpkgs as the `nixpkgs.source` module options.
This only happens when `evalNixvim` is part of a lib that was provided
`flake` as an argument.
Stubbed the `nixpkgs.source` option for now. Eventually, this will be
used to construct `pkgs` internally. For now, it's purely informational.
Based on the `nixpkgs.overlays` option available in NixOS, allows users
to further customize the `pkgs` instance used when evaluating nixvim.
The standard module tests are now provided a few extra module args to
enable a test where we instantiate a custom nixpkgs instance.
This minimal implementation allows `nixpkgs.pkgs` to be defined, but
does not implement evaluating an instance from a pkgsPath when _not_
defined.
The `defaultPkgs` specialArg is dropped in favour of `nixpkgs.pkgs`
being defined. If it's not defined, an assertion is thrown.
In the future, a nixpkgs source path can be supplied, defaulting to the
flake's `inputs.nixpkgs`. Along with other `nixpkgs.*` options, this
will allow a `pkgs` instance to be evaluated within the module eval.
Matt Sturgeon
Austin Horstman
Adam Dinwoodie
rekcäH nitraM
Wolfgang Walther
Axel Karjalainen