Under what conditions does lazy.nvim install into ~/.local/share/*/lazy?

[rishyramen]

I tested out nixCats w/ lazy wrapper on a couple and I opened up :Lazy to verify install directories. I noticed it showed my theme, kanagawa.nvim, as installed in ~/.local/share/nixCats/lazy instead of the plugin package directory in the nix store. The other plugins it shows them as installed in the store. Is this expected behavior?

Also I think if I go to the Update tab in :Lazy it will then install all the plugins into my system nvim data directory ~/.local/share/nvim/lazy... and then shows those that location as the install directory. Does this mean we should avoid accidentally updating plugins through lazy?

I'd greatly appreciate any clarification so I know what to be aware about when managing my installs with nixCats + lazy. Just trying to migrate my current setup at the moment but in the future I will definitely consider moving to lz/lze . Thank you!

[BirdeeHub]

So, nixCats provides a small wrapper you can add via the luaUtils template here is the function

You call it instead of the require('lazy').setup function, and it is the same, other than taking 1 extra argument as the first argument.

What it will do is set a few settings so that lazy.nvim will look for plugins in their dev paths first, and then call the lazy setup function.

It does these things:

• it allows you to provide the path to lazy.nvim from nix, and if not found (if the first argument you gave was nil and not a string) fall back to the normal bootstrap steps. (you can get this path via nixCats.pawsible in lua)

• It sets dev.path such that if the name of the spec matches the name of something provided from nix, it will give the path provided by nixCats.pawsible, otherwise it will fall back to the normal dev.path setting.

• It sets dev.patterns to { "" } so that it tries to find the dev path for each plugin first

• It sets dev.fallback such that if its not found in the dev path, it will download it.

• It sets performance.rtp.reset = false and then does the rtp reset itself in such a way that it doesnt remove your config directory and treesitter parsers from the rtp.

In practice, this means that as long as the pname of the plugin from nix matches the last part of the url, lazy.nvim will get the one in the path from nix, and treesitter parsers provided from nix that have been passed through vimUtils.grammarToPlugin should just work

if the pname of the plugin from nix does not match the one from lazy.nvim, lazy.nvim will attempt to download it. If this happens, you can set the name field of the lazy.nvim spec, or you can set it from nix by putting {name = "somename"; plugin = pkgs.vimPlugins.whatever; } in the list in nix instead.

You can see the names provided from nix by running :NixCats pawsible, and as long as those names match what lazy.nvim thinks the name is, it will get the nix provided one, and not attempt to download.

[BirdeeHub]

https://github.com/BirdeeHub/nixCats-nvim/tree/main/templates/kickstart-nvim

This template is intended as a tutorial on doing that.

You can choose to let lazy do it, or do it from nix by just downloading it via nix and occasionally fixing its name.

lazy.nvim will function as normal unless it finds a matching name in nixCats.pawsible("allPlugins.start") or nixCats.pawsible("allPlugins.opt")

[rishyramen]

Thank you you so much! I actually was using the kickstarter template but completely missed the :NixCats pawsible command.. The issue was I was thought I had to match the name in the plugin spec with the name of the attribute and wasn't aware of pname... Everything's good now though, thank you :)

[BirdeeHub]

Every table nixCats provides has an associated debug subcommand of the same name in the :NixCat user command :)

The display is currently a little basic, it opens a popup buffer with vim.inspect of the table and highlights it like lua

That may improve eventually, but it is still useful and you can search in it like a normal buffer so... yeah. There might be a better dashboard someday but it is currently at least still useful.

[BirdeeHub]

also, in the lazy dashboard it colors dev dependencies differently from the ones it downloaded, and will list the nix store path, so that is very useful for getting a quick visual for if the name matched and it all worked as expected when trying to download via nix and getting lazy to find it.

[BirdeeHub]

The main reason you might want to swap off of lazy.nvim is that there are a lot of plugins that actually dont require any setup

For example, rustaceanvim? You just install that as a startupPlugin and install the lsps. You dont need to do anything in lua for that, it handles it, it loads on rust only, etc.

But in lazy.nvim, it would still need a spec for it, even if the spec was minimal. Its still another layer in between what is going on

Whereas with lze, it uses nvim's packpath. If the thing is in optionalPlugins, it can load it on a trigger, otherwise if it was in startupPlugins it will load at startup. (this can be overridden by setting optional = true on a per plugin basis as well much like the name thing)

Pretty much every nvim package manager uses the packpath outside of lazy.nvim, and the ones that dont can be made to work by changing the load function used by default, but I have found paq and rocks to work best with lze outside of nix. It works great with nix, as nix just makes some directories and puts them on the packpath.

lze is a much simpler model that doesnt force you to use it for everything, whereas with lazy.nvim you basically have to use it for everything or not use it at all.

I generally recommend lze over lz.n because it has more affordances for things that care about initialization order, such as having dep_of and on_plugin and on_require handlers built in, because while most plugins shouldn't care, many do care what came first. But also lze is my own version of lz.n so obviously Im going to recommend it, so make your own decision between lze and lz.n, dont let me sway you too hard. The handlers work differently, the specs work similarly, although the import spec works differently.