collect and add to PATH runtimeinputs of neovim plugin dependencies

[teto]

Issue description

There has been talk to better handle runtime inputs for nixpkgs. Now that the wrapper sees the plugins directly it's easier to collect plugin runtime dependencies. I am not sure how other ecosystems do it (runtimeDependencies ? passthru.runtimeDeps ? ) but we could go through each plugin dependencies and add them to PATH in the wrapper.

For reference: https://github.com/NixOS/nixpkgs/issues/347093 https://github.com/NixOS/nixpkgs/pull/208029

cc interested folks @khaneliman @GaetanLepage @figsoda @PerchunPak @mrcjkb

This should probably wait for after the nixos 24.11 release to give us more time to experiment but a proposition could be made beforehand.

[GaetanLepage]

testing cc @NixOS/neovim

[GaetanLepage]

I guess that it would correspond to propagatedInputs (or dependencies for python3Packages.*).

[MattSturgeon]

I guess that it would correspond to propagatedInputs

Not strictly, because inputs are only on the PATH while in a stdenv (i.e. while building the derivation or in a devshell for the derivation); at runtime they are locked away in the nix store.

(or dependencies for python3Packages.*).

Yeah, or runtimeInputs for writeShellApplication.

I haven't looked at the implementation for python's dependencies attr, but writeShellApplication simply prepends lib.makeBinPath finalAttrs.runtimeInputs to the PATH env-var, in the resulting shell script.

[mrcjkb]

I'm guessing this only applies to runtime dependencies like C libraries that are called via FFI? For things like language servers, I wouldn't want a Neovim plugin resulting in those being pulled and added to the PATH. I typically add them to devShells.

[MattSturgeon]

I'm guessing this only applies to runtime dependencies like C libraries that are called via FFI? For things like language servers, I wouldn't want a Neovim plugin resulting in those being pulled and added to the PATH. I typically add them to devShells.

No I think we are talking about any exe dependency that could go on the PATH, including LSPs.

However we are only talking about the PATH defined by nvim's wrapper script. Outside of neovim your PATH would be unmodified.

Conceptually, a wrapper script functions similarly to a nix shell. Primarily, it serves to define the environment needed to run the program (nvim).

You raise a good point regarding how things should work when an end-user wants to provide dependencies in an impure way, by having them available in the wider environment.

Maybe such users should be telling the nvim wrapper to not provide specific dependencies?

[teto]

For things like language servers, I wouldn't want a Neovim plugin resulting in those being pulled and added to the PATH.

Yet I think that's what many users expect, would hope for. See mason/nixvim etc. But if that can "reassure" you, this behavior would be off by default.

Maybe such users should be telling the nvim wrapper to not provide specific dependencies?

makeWrapper accepts --prefix, --set, --suffix to PATH depending on what you want to use. I believe here --suffix would let neovim see the devShell program. It's also my preference but looking at home-manager's tracker, there are various opinions on the subject :'(

[mrcjkb]

However we are only talking about the PATH defined by nvim's wrapper script. Outside of neovim your PATH would be unmodified.

But if that can "reassure" you, this behavior would be off by default.

That should definitely be configurable. I wouldn't mind it being on by default, but it should be possible to disable it. Some language servers can take quite a while to start up, and can slow down everything on my not so beefy laptop. Sometimes I just want to edit or peek some files quickly, using traditional ctags for navigation, and using a repl for compilation when I need it.

I believe here --suffix would let neovim see the devShell program.

We should definitely do this. Some language servers (e.g. rust-analyzer, haskell-language-server-wrapper) need to match the toolchain of the project, so there could be issues when using the one on nvim's path. This is one of the most common issues I see with rustaceanvim users who use mason.nvim to install the language server.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/home-manager-cannot-get-vimplugins-coc-vimtex-or-vimplugins-coc-texlab-to-work/55487/2

[teto]

runtimeDeps looks popular in nixpkgs and I like it, it's quite self-explanatory. I can do that after https://github.com/NixOS/nixpkgs/pull/356271 if no one beats me to it.

[teto]

started https://github.com/NixOS/nixpkgs/pull/358587