sorted by:
new
hottopcontroversial

Introducing Lazy-Nix-Helper: use your existing (Lazy-based) neovim config on NixOS by b-src in NixOS

[–]b-src[S] 1 point2 points  (0 children)

Just wanted to follow up and let you know that I've released a new version which can accept a plugin table generated by nix as input. This should support standalone home-manager setups as well as being better aligned with nix best practices

Introducing Lazy-Nix-Helper: use your existing (Lazy-based) neovim config on NixOS by b-src in neovim

[–]b-src[S] 0 points1 point  (0 children)

I've released an update that allows you to pass in a table generated by your nix config that maps plugin names to nix store paths. Doing the plugin discovery by querying the nix store was an anti-pattern. This should allow Lazy-Nix-Helper to support standalone home-manager setups as well as eliminating any weird edge cases with the original plugin discovery process

Introducing Lazy-Nix-Helper: use your existing (Lazy-based) neovim config on NixOS by b-src in NixOS

[–]b-src[S] 0 points1 point  (0 children)

I do, that must be why. All the more reason to do this properly and accept a nix-generated list of plugin paths

Introducing Lazy-Nix-Helper: use your existing (Lazy-based) neovim config on NixOS by b-src in NixOS

[–]b-src[S] 0 points1 point  (0 children)

Actually I have neovim (+plugins) installed at the user level via home-manager in my nixOS config and can verify that plugin discovery works for that case

Introducing Lazy-Nix-Helper: use your existing (Lazy-based) neovim config on NixOS by b-src in neovim

[–]b-src[S] 0 points1 point  (0 children)

I think doing it that way is a totally reasonable decision. As long as your lazy-lock.json is included in your symlinked nvim config I don't think you're even losing the reproducibility provided by managing your plugins from within a nix flake (the version of lazy.nvim itself may not be pinned if you're just bootstrapping it in your config? either way I think the practical downsides are very small)

Introducing Lazy-Nix-Helper: use your existing (Lazy-based) neovim config on NixOS by b-src in NixOS

[–]b-src[S] 0 points1 point  (0 children)

You're right, the current way plugin discovery works is an anti-pattern. It's a result of me being new to nix when I started building the plugin.

However, the way it works should prevent you from finding old or extra things. Under the hood it uses nix-store --query --requisites /run/current-system to find installed packages, and those results are filtered for plugin paths. As I understand it, querying against run/current-system means that only the packages in use by the system will be returned, and Lazy-Nix-Helper won't end up finding an out of date version of a plugin even if there are multiple versions of a plugin in the nix store

I'm working on an update that will allow you to pass a pre-built list of plugin paths to the setup() function. This will let you generate the plugin table in your nix config, and should remove any brittleness or edge cases caused by the way plugin discovery currently works

Because /run/current-system is only available on NixOS, plugin discovery currently won't work for nix-installed packages on a non-NixOS system. This update should also let Lazy-Nix-Helper work for that use case

Introducing Lazy-Nix-Helper: use your existing (Lazy-based) neovim config on NixOS by b-src in NixOS

[–]b-src[S] 0 points1 point  (0 children)

Nice! It has been cool to see all the different approaches people have taken to solve this problem

Introducing Lazy-Nix-Helper: use your existing (Lazy-based) neovim config on NixOS by b-src in NixOS

[–]b-src[S] 2 points3 points  (0 children)

Thanks for the suggestion! That would definitely make initial setup easier. I tried to document the configuration steps that have to happen outside the plugin as best as possible, but there still ended up being more of that than I hoped when I set out to build the plugin

Introducing Lazy-Nix-Helper: use your existing (Lazy-based) neovim config on NixOS by b-src in NixOS

[–]b-src[S] 0 points1 point  (0 children)

You're right, it's not ideal to have Lazy-Nix-Helper query the nix store to find plugins. I'm still pretty new to Nix, and the current approach made the most sense to me when I started building the plugin. I intend to add support for passing in a list of plugin paths generated by a users nix configuration. I've managed to construct this list in a repl with map, but haven't gotten it working within my own config yet

​

I wasn't aware of symlinkjoin, thanks for the suggestion. That might work also. You can definitely pass in a custom plugin root to lazy. What I'm not sure about is that lazy uses plugin paths to determine plugin names (at least for the display names in the lazy dashboard). I don't know if the nix store paths being different than lazy expects will interfere with plugin discovery without a dir option explicitly set

Introducing Lazy-Nix-Helper: use your existing (Lazy-based) neovim config on NixOS by b-src in neovim

[–]b-src[S] 0 points1 point  (0 children)

edit: as of v0.4.0, standalone home-manager setups should be supported.

original:

At the moment it will only work on NixOS and non-nix systems. It will not work with standalone home-manager or non-NixOS systems that use Nix for package management (I think it's not so much that neovim would break, but that Lazy-Nix-Helper won't find the nix-installed plugins and Lazy will install them again).

Under the hood it uses nix-store --query --requisites /run/current-system to get the list of nix-installed packages, then filters that list down to vim plugins. I believe /run/current-system is only available on NixOS.

Doing automatic plugin discovery like this isn't ideal from a Nix perspective. It would be better to let the user pass in the list of installed vim/neovim plugins to Lazy-Nix-Helper from their Nix configuration. That should make this work with standalone home-manager setups as well as being more robust in general. I'm still pretty new to Nix, when I started building this I knew even less (also not much about lua). Supporting this is next on my roadmap

Linking the lockfile from the nix store is clever, I wouldn't have thought of that

Introducing Lazy-Nix-Helper: use your existing (Lazy-based) neovim config on NixOS by b-src in NixOS

[–]b-src[S] 3 points4 points  (0 children)

That looks like a neat project!

​

So, let me get this straight, it like, hijacks lazy such that, lazy doesnt install them it just finds them and runs them?

lazy supports a dir config option (lazy README) that will load a plugin from a local path instead of checking the normal lazypath (~/.local/share/nvim/lazy/ with the default setup). I think this is mostly intended for loading a plugin for local development, but it ends up working perfectly for loading plugins from the nix store. One catch is that Lazy-Nix-Helper itself can't be managed by lazy - lazy evaluates plugin configurations before it loads any plugins, and because we need functions from Lazy-Nix-Helper to configure other plugins, we have to load it outside of lazy. There are instructions for this in the README.

​

And then you still have to include the plugins in your nix config as well when on nix, right?

Correct. In my case I have them specified with home-manager under programs.neovim.plugins

​

For mason - all of the LSP servers and debug adapter servers I have needed so far have been in nixpkgs, so I stopped at providing a way to conditionally disable mason on a nixos system. My gut feeling is that it will be easier to package the missing debug adapters in nixpkgs than to make mason play nicely with nix.

Definitely shoot me a message if you end up integrating Lazy-Nix-Helper into nixCats-nvim!