neovim: add 'autowrapRuntimeDeps' to append

[teto]

Fix #352738

TLDR, adds runtime dependencies of vim plugins to the neovim wrapper PATH

I based it upon #356271 which hopefully will get merged

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[PerchunPak]

Why having it opt-in? We already apply a wrapper to each plugin, no?

[teto]

I thought we might have it opt-in at first to get feedback,to update the plugins with their runtimeDeps as well. And in a second step we would make it opt-out. We coul opt-in straightaway as well, I dont mind.

[teto]

one issue with the opt-out is that it forces us to update the doc in a way that works with the legacy and new wrapper, which should be done but I am too lazy to do yet :'( I would rather document the new wrapper in another PR

[PerchunPak]

Could you remind me please where is documentation for the wrapper?

[PerchunPak]

I don't see a reason for changing plugins to use runtimeDeps in a subsequent PR. We can do it here to tackle problems before merging the feature. Unless you don't want to do this right now

But yeah, we can keep it opt-in for now, though I doubt someone would use opt-in undocumented features outside of [@]NixOS/neovim team

[teto]

if we stop patching the plugins because of this PR, then disabling autowrapRuntimeDeps would entail user regressions so you are right we might need to enable it by default straightaway. @mrcjkb would opt-out by default be okay with you ?
You might see regressions for some plugins where paths would stop being hardcoded. Mixing an apt neovim with a nix plugin would stop working for instance (contrary to today). I beliee it's fine to not support these scenarios since not patching plugins makes maintaining plugins easier, we better respect upstream and it means plugins work on neovim as on other distributions: you can override the dependencies without having to regenerate the whole system

[teto]

the test nix-build -A neovim.tests.autowrap_runtime_deps now passes.
the neovim used in the test nix-build -A neovim.tests.nvim_with_runtimeDeps correctly wraps xxd when installing the plugin pkgs.vimPlugins.hex-nvim with autowrapRuntimeDeps = true;.

Feel free to test it out thought it wont do much without updated plugins. The candidates could be:

• sniprun
• every lsp plugin, schemastore to include yamlls for instance (but can it work with others).

Feel free to complete the list.

[khaneliman]

the test nix-build -A neovim.tests.autowrap_runtime_deps now passes. the neovim used in the test nix-build -A neovim.tests.nvim_with_runtimeDeps correctly wraps xxd when installing the plugin pkgs.vimPlugins.hex-nvim with autowrapRuntimeDeps = true;.

Feel free to test it out thought it wont do much without updated plugins. The candidates could be:

* sniprun

* every lsp plugin, schemastore to include yamlls for instance (but can it work with others).

Feel free to complete the list.

Did you want us to add runtimeDeps to the packages in this PR or just add notes about other possible updates?

[teto]

Until we coordinate with vim such that they do the same as us, we should use autowrapRuntimeDeps for neovim plugins exclusively OR to add software we dont patch already, like the LSP servers.

We can unpatch plugins later if nixpkgs vim maintainers agree, discussion at: #352738 (comment)

I am tempted to merge under these conditions what do you think ?

[khaneliman]

Until we coordinate with vim such that they do the same as us, we should use autowrapRuntimeDeps for neovim plugins exclusively OR to add software we dont patch already, like the LSP servers.

We can unpatch plugins later if nixpkgs vim maintainers agree, discussion at: #352738 (comment)

I am tempted to merge under these conditions what do you think ?

I think it's an improvement to allow wrapping runtime deps instead of patching. Even if we don't handle all occurrences immediately.

[teto]

let's add it to one or two plugins, if that works, we default to true and mention it in doc + 25.04 changelog.