neovim: set provider configuration to initrc

[teto]

Things done

as an attempt to simplify configuration. Third parties can just refer to the generated init.lua instead of having to refer to it + regenerate the wrapper arguments (ruby still needs special treatement via GEM_HOME set apparently).

I wonder if this needs release notes, I dont know if nixvim / kickcats depend on the nixpkgs wrapper or if it just rewrites the whole logic.

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

[teto]

for context, I would like to make it possible for home-manager to just skip wrapping neovim-unwrapped entirely in most cases. Also I noticed we have withRuby ? true in wrapNeovimUnstable which I find odd especially as the legacy wrapper defaults it to false. I might disable it in a separate PR.

[khaneliman]

What would be the result of losing these providerLuaRc variables for a downstream consumer of the wrapper?

Before:

exec "/nix/store/wr7j2629j0hmipa1mb966xagk174q5ky-neovim-byte-compiled-0.11.6/bin/nvim"  --cmd "lua
vim.g.loaded_node_provider=0;vim.g.loaded_perl_provider=0;vim.g.loaded_python_provider=0;vim.g.python3_host_prog='/nix/store/c4bfr9cl8nmlggzjg40q3z5pvalpgpkz-neovim-0.11.6/bin/nvim-python3';vim.g.ruby_host_prog='/nix/store/c4bfr9cl8nmlggzjg40q3z5pvalpgpkz-neovim-0.11.6/bin/nvim-ruby'" --cmd "set packpath^=/nix/store/q8cjdv0idypwjypmai84mg4g1pymws3a-vim-pack-dir" --cmd "set rtp^=/nix/store/q8cjdv0idypwjypmai84mg4g1pymws3a-vim-pack-dir" -u
/nix/store/g8d7m5y1alrh0w71phig6kyah9q2b66v-init.lua "$@"

After:

exec "/nix/store/wr7j2629j0hmipa1mb966xagk174q5ky-neovim-byte-compiled-0.11.6/bin/nvim"  --cmd "set packpath^=/nix/store/xssf72bmwy0pqhb8sk4rz3djs4nww7rp-vim-pack-dir" --cmd "set
rtp^=/nix/store/xssf72bmwy0pqhb8sk4rz3djs4nww7rp-vim-pack-dir" -u /nix/store/86sl0w2kp7f6hm6vqhhpqb75gvy5lfhn-init.lua "$@"

Is this just going to make Neovim search for those on PATH instead of automatically including the direct paths?

[teto]

nope the same code is included in the generated rcContent instead https://github.com/NixOS/nixpkgs/pull/487390/changes#diff-647e8d1c5843195e278d71753f17d2183d961166104c8c55edc4cb93768579ddR108

[teto]

i.e a plain user should not see the difference, someone setting wrapRc = false will be fine if he already includes the wrapper luaRcContent somehow. If he doesn't, now he must :p

[khaneliman]

I guess what I was trying to figure out was, this is technically a breaking change that generates a different wrapper for those relying on it from there. What is the effect of that no longer being included in the wrapper and / or recommended migration for consumers of the existing wrapper semantics?

Should probably have a short blurb in release notes about the behavior changing so there's something to reference if a config stops working how it had before the change.

Just trying to avoid surprising people with undocumented changes if they will affect neovim at runtime.

[khaneliman]

Maybe i'm being overly cautious @mrcjkb any thoughts?

[mrcjkb]

Before this PR, the neovim wrapper was invoked with

nvim --cmd ":lua ${providerLuaRc}" "$@"

--cmd flags are invoked after init.lua (you can test this by adding vim.g.foo = "hello" to your init.lua and then running nvim --cmd ":lua vim.print(vim.g.foo or 'foo unset')").

So this PR moves the sourcing of the providerLuaRc to an earlier point of Neovim's startup sequence.

Technically, a config could break if it tries to use one of the providers in the init.lua and the user doesn't know that they have it disabled.
I think it's highly unlikely, as providers are typically used by plugins and Neovim loads providers lazily using :h autoload scripts.
For example, the python provider is only loaded if a user or a plugin calls the Vimscript function provider#python3#Call or provider#python3#Require.

[teto]

If anything setting the providers earlier could fix things where a plugin checks if the provider is set (and currently thinks it's not). I doubt many users use remote plugins. With the remark of marc, I've updated the commit description to :

1. mention who might be concerned ( which I think is really a small number)
2. how to fix that in those degenerate cases

[teto]

while I think the change is fine for nxipkgs users, it's a bit annoying in home-manager so I will reference it in the nixpkgs changelog. Also I need to complete nix-community/home-manager#8734 before merge

[GaetanLepage]

Also I need to complete nix-community/home-manager#8734 before merge

Ok, I will mark this PR as draft in the meantime.

[teto]

Ok, I will mark this PR as draft in the meantime.

ty I should have done so. Putting it out of draft since I've fixed the issues in the HM PR. It took me more time than I wanted but it's an iterative progress as we try not to break configs.
I would like to merge this,

I've suffered from (my) poor naming choice in the wrapper variables, so some notes for possible naming improvements:

• why do I need precise "neovim" in neovimRcContent' when we are in the neovim wrapper
• we have luaRcContent = rcContent different from the passed wrapper luaRcContent (which might be voluntary because I wanted users to be able to chain their config via neovim.overrideAttrs(oa: { plugins = .. }).overrideAttrs(oa: { plugins = oa.plugins ++ [ .. ]}).overrideAttrs({ withRuby = false;})such that you dont need to know your full config in advance.
• in my experience, what I am interested in the exposed variables is: "user" or "generated", "lua" or "viml" so naming should reflect that.

[stefanboere]

This change breaks my config because the vim.g.python3_host_prog refers to incorrect path.

Contents of the file /nix/store/8y45ym4ab9kbcam4vz4j83xfxkx9jf95-init.lua:

vim.g.node_host_prog='/nix/store/8y45ym4ab9kbcam4vz4j83xfxkx9jf95-init.lua/bin/nvim-node';vim.g.loaded_perl_provider=0;vim.g.loaded_python_provider=0;vim.g.python3_host_prog='/nix/store/8y45ym4ab9kbcam4vz4j83xfxkx9jf95-init.lua/bin/nvim-python3';vim.g.loaded_ruby_provider=0
vim.cmd.source "/nix/store/m3nif8y02vkll3hcml4cz9rnm1zdk98v-init.vim"

But it should refer to the neovim store path itself, not the init.lua store path. So the file nix/store/8y45ym4ab9kbcam4vz4j83xfxkx9jf95-init.lua/bin/nvim-python3 does not exist.

So now in neovim I get the error 'E319: No "python3" provider found.'

[teto]

ty for warning. If you dont need the python provider, you can disable it via withPython3 = false until it gets fixed. Actually I think we should change all the providers default to false.

[stefanboere]

Yes thank you, I'll just revert to earlier version, no problem. But I send this comment because probably more vim users will get this error, so I was wondering if this could be fixed or otherwise if the commit could be reverted.

And thank you for the effort with this PR and cleaning up the vim configuration :).

[mrcjkb]

The problem seems to be that generateProviderRc uses ${placeholder out}:

nixpkgs/pkgs/applications/editors/neovim/utils.nix

Line 267 in 09ac1a4

"vim.g.${prog}_host_prog='${placeholder "out"}/bin/nvim-${prog}'"

...which now evaluates to init.lua, since providerLuaRc is now part of the initrc.
I think besides reverting this PR, the only fix is to put each provider in its own derivation.

[teto]

I think besides reverting this PR, the only fix is to put each provider in its own derivation.

I can think of other solutions though, like inlining the code. generateProviderRc is a bad abstraction with the placeholder out a footgun. I wanted to avoid the revert but there are too many things that seem wrong at the moment that I would prefer to address first. So le'ts revert. I seem to remember it was possible to revert from github's UI but I can t find it anymore ?
gotta do it the old way then.

EDIT: found the button

[nixos-discourse]

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

https://discourse.nixos.org/t/neovim-provider-options-not-working/76077/2