Extracting `specialArgs.lib.nixvim` from the final `programs.nixvim`
configuration is neat, but recursive. In non-lazy scenarios, it can end
up infinitely recursive.
We could extract `specialArgs.lib.nixvim` from another nixvim
configuration, such as one of the earlier `extendModules` evaluations,
however it is better to avoid evaluating multiple configurations
unnecessarily.
Instead, revert back to getting `lib.nixvim` from the same configuration
we get `extendModules` from.
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
Wrapped Nixvim configs previously passed the generated init.lua with -u. Neovim treats that startup path as an explicit user config and skips exrc processing, so project-local .nvim.lua files were not sourced even when users enabled the exrc option.
Load the generated config through a forced VIMINIT instead. This preserves the current wrapped-config precedence while allowing Neovim's normal exrc startup path to run for trusted project config files.
When impureRtp is disabled, clear XDG_CONFIG_DIRS and VIM from an early --cmd before sysinit is checked, then restore them before loading the generated config so runtime code and child processes see the original environment.
Keep the saved startup environment in a short-lived global Lua table shared between the --cmd and VIMINIT chunks, then clear it after restore.
Add a modules-output regression test that checks the wrapper args no longer include -u, verifies VIMINIT is set, confirms trusted .nvim.lua is sourced, blocks sysinit.vim, verifies XDG_CONFIG_DIRS and VIM are restored, and ensures the saved startup state is cleared.
Closes#3506
Separate `overlay.nix` and `overlay.internal.nix`, to encapsulate the
`flake` argument. This allows non-flake users to import `./overlay.nix`
without providing a dummy `flake = null` attr.
The read-only `config.flake` option is only defined by `evalNixvim` when
`lib` is extended using the overlay in Nixvim's flake outputs.
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.
warning: Dependency of package 'python3.13-python-lsp-server-1.14.0' uses a nested list in attribute 'propagatedBuildInputs'.
This is deprecated as of Nixpkgs release 26.05, and support will be removed in a future nixpkgs release.
Pass the LspAttach autocmd event into the shared onAttach helper so existing configs can still read event.buf and event.data.client_id after dynamic registration support moved the user body out of the autocmd callback.
For registerCapability reruns, provide a synthetic event with the fields Neovim documents for LspAttach that nixvim can still know: buf and data.client_id.
Fixes#4335
Some LSP servers register capabilities after LspAttach, so the global onAttach body must also run from client/registerCapability for buffers already attached to that client.
Keep the initial LspAttach autocmd for servers that advertise capabilities up front, and preserve the wrapped handler's return value.
Closes#3323
Gaetan Lepage
nixvim-ci[bot]andGaétan Lepage
Matt SturgeonandGaétan Lepage
Austin Horstman
Adam DinwoodieandMatt Sturgeon
rekcäH nitraMandMatt Sturgeon
Wolfgang WaltherandMatt Sturgeon
2kybe3andGaétan Lepage