lunarvim: init at 1.3.0

[ProminentRetail]

Description of changes

Follow-up to #257063. Closes #178488 and LunarVim/LunarVim#1507.

Differences to the original PR:

• Implemented globalConfig to replicate neovimRcContent) by inserting a line here prior to the post-load hook for the configuration.
• Implemented nvimAlias, viAlias and vimAlias by mimicking neovim.
• Instead of invoking install_bin.sh, I generate the launch script manually. This turns out to be simpler since I need to replace the nvim call to be compatible with nvimAlias anyway.
• I include cargo, make and nodejs as per LunarVim's prerequisites.
• I include curl, gzip, gnutar and unzip as per mason.nvim's requirements.
• LunarVim (mason.nvim) will automatically pull lua-language-server out of the box as soon as a Lua file is opened; this will happen for virtually every user since the configuration is in Lua. However, the mason.nvim installation is not functional, as the Nixpkgs derivation does some extra stuff to make things work. I'm solving this by adding lua-language-server manually and giving our version priority by causing the mason.nvim binary path to be appended rather than prepended. This will also allow users to easily override any other language server binaries causing problems.
• I include stdenv.cc to get nvim-treesitter to work.
• I generate the default configuration.
• I'm pulling in a patch to fix Nerd Fonts until the next release is pushed.

Considerations:

• telescope.nvim technically does not declare fd and ripgrep as required dependencies, but we're including them by default anyway (also see Dependency for Telescope: fd LunarVim/lunarvim.org#333). This makes sense to me since LunarVim's philosophy is to have "sane defaults", but I have no real conviction here.
• Following this logic, should we also include lazygit by default as per LunarVim's optional feature prerequisites?
• I also agree with the logic here that installing all the optional dependencies for mason.nvim would be overkill.

Thanks! 😸

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• 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/)
• 23.11 Release Notes (or backporting 23.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.

I don't like vi

[buckley310]

Works for me 👍

I am, however, still pulling in the patch mentioned here, because lvim 1.3.0 doesn't work with nixpkgs's version of nerdfonts.
#257063 (comment)

[ProminentRetail]

Works for me 👍

I am, however, still pulling in the patch mentioned here, because lvim 1.3.0 doesn't work with nixpkgs's version of nerdfonts. #257063 (comment)

This is fair—having a broken out-of-the-box interface is an annoying experience, and there is no indication as to when the next release will be pushed.

[benwis]

@ProminentRetail Does it really need cargo to build? I ask because I'm managing rust/cargo separately with rust-overlay

[ProminentRetail]

@ProminentRetail Does it really need cargo to build? I ask because I'm managing rust/cargo separately with rust-overlay

I don't think it strictly does; I've included cargo and nodejs because they're mentioned as a prerequisite on the LunarVim site. However, it might be a better idea to leave them out by default.

[benwis]

Ok, I installed using your package, and it mostly works, except it cannot create or access ~/.config/lvim/config.lua on the first run. Somehow though, this error went away on the next run. The nerdfont iconset doesn't seem to be included as a dependency, and manually adding nerdfonts to the devshell doesn't seem to fix it

[teto]

Let me go on a siderant: I am not a fan of those vim distribs because IMO they sidestep the issue, a (GUI) tool that can help generate a proper neovim config aka sthg like https://github.com/teto/vim-config . Nevertheless they are a good way for newbies to show what is possible.

Lvim downloads and builds some of its tools at runtime. Some of these are rust. So not all the language integration will work without cargo.

These distribs make even less sense on nixpkgs IMO because one of their major business is to install software but nix makes it even more reliable. I expect people to run lvim because they want something convenient they dont have to fiddle too much with. In that context, I think it makes sense to lean on providing more software rather than less. I would provide cargo for instance (not in the global PATH, just visible from neovim by wrapping neovim with cargo in its PATH like home-manager does in programs.neovim.extraPackages)

[ProminentRetail]

Let me go on a siderant: I am not a fan of those vim distribs because IMO they sidestep the issue, a (GUI) tool that can help generate a proper neovim config aka sthg like https://github.com/teto/vim-config . Nevertheless they are a good way for newbies to show what is possible.

I use LunarVim because I don't want to have to think too hard about all the boilerplate, and it has a decent-sized community. The idea that I can just add lunarvim to systemPackages and have almost everything I want in an editor is very appealing to me.

These distribs make even less sense on nixpkgs IMO because one of their major business is to install software but nix makes it even more reliable.

I hear you, but for something as dynamically personalised as an editor, I appreciate the happy medium that a LunarVim configuration provides in declarativeness, lack of extra fiddling, and rapid iteration. Of course, my opinion is very liable to change. :P

I expect people to run lvim because they want something convenient they dont have to fiddle too much with. In that context, I think it makes sense to lean on providing more software rather than less. I would provide cargo for instance (not in the global PATH, just visible from neovim by wrapping neovim with cargo in its PATH like home-manager does in programs.neovim.extraPackages)

I definitely agree that the whole point is to provide a frictionless, friendly out-of-the-box experience; I've been pulled back and forth on this, but I do think including Cargo and npm by default aligns with this philosophy. Is there any problem with the way I'm currently including runtime dependencies by calling wrapProgram on lvim? Users can override buildInputs with their own additional packages if they need, or they can pass in their own wrapped version of neovim.

[teto]

Looks ok to me. I am not the best to check if it doesn't break lunarvim but we can iterate on it anyway.

[gfsd3v]

everything worked perfectly, even when I copied my custom config into the lunarvim directory, truly amazing, great job 👏

not sure if is needed, but I had to add gnumake to my pkgs bc is a dependency of nvim-telescope/telescope-fzf-native.nvim, which I believe to be a core package for lunarvim features, maybe worth to add it. Thanks again 💚

[teto]

not sure if is needed, but I had to add gnumake to my pkgs bc is a dependency of nvim-telescope/telescope-fzf-native.nvim, which I believe to be a core package for lunarvim features, maybe worth to add it. Thanks again 💚

Instead of adding gnumake, would it make sense to include the nix plugin telescope-fzf-native.nvim in the neovim wrapper instead ? depend on if lunarvim wants to control the version of the plugin.

[gfsd3v]

Instead of adding gnumake, would it make sense to include the nix plugin telescope-fzf-native.nvim in the neovim wrapper instead ? depend on if lunarvim wants to control the version of the plugin.

afaik lunarvim doesn't have any type of version lock system for plugins, u are free to manage plugins version using Lazy, it has the risk of braking some lunarvim features depending on the update, but I believe that is expected

[ProminentRetail]

everything worked perfectly, even when I copied my custom config into the lunarvim directory, truly amazing, great job 👏

Great to hear!

not sure if is needed, but I had to add gnumake to my pkgs bc is a dependency of nvim-telescope/telescope-fzf-native.nvim, which I believe to be a core package for lunarvim features, maybe worth to add it. Thanks again 💚

Is gnumake not already being pulled?

[ProminentRetail]

Instead of adding gnumake, would it make sense to include the nix plugin telescope-fzf-native.nvim in the neovim wrapper instead ? depend on if lunarvim wants to control the version of the plugin.

I think it makes sense to relinquish control of plugin management to LunarVim.

[gfsd3v]

Is gnumake not already being pulled?

For me it wasn't pulled, I got the error at the first LunarVim start when Lazy.vim begins downloading the plugins, after adding it to my system pkgs it worked as expected.

[ProminentRetail]

Is gnumake not already being pulled?

For me it wasn't pulled, I got the error at the first LunarVim start when Lazy.vim begins downloading the plugins, after adding it to my system pkgs it worked as expected.

Hm, this is really weird. I don't have make in my global path, and it works just fine from LunarVim.

[ProminentRetail]

I've just realised that we need to include stdenv.cc to get nvim-treesitter to work.

[anthr76]

@ProminentRetail would it be possible for you to package AstroNvim as well? Thank you very much for this.

[gabyx]

Jeah Astrovim would be very nice.

Can we help here in some way?

[gfsd3v]

@ProminentRetail the next release of LunarVim is taking a while, I was thinking about overriding to use master instead of 1.3.0, I've noticed here that u are using tags and fetchFromGitHub to "get LunarVim", I'm not too versed on Nix, LunarVim doesn't have a master tag (obviously), any suggestion on how to go about overriding this to fetch from master?

[buckley310]

how to go about overriding this to fetch from master?

rev can also be set to a commit hash.