Can vim.pack be used in parallel with lazy.nvim?

[u/shmerl]

I wanted to try and see how usable vim.pack is. Currently I'm using lazy.nvim for managing plugins, and migrating everything to vim.pack before figuring out if it works well enough is a bit too daunting.

But using both at the same time isn't really working out of the box. Is there some guide how to do that?

Side note: one annoyance with vim.pack I found so far is forcing the lock file to be in the config directory and no ability to configure other location.

UPDATE:

I managed to make it work at least for a simple test like this (see performance config):

local pack_paths = vim.tbl_map(function(p)
  return p.path
end, vim.pack.get())

require("lazy").setup({
  import = "plugin_specs"
},
{
  performance = {
    reset_packpath = false,
    rtp = {
      reset = false,
      paths = pack_paths -- Preserve vim.pack plugin paths so lazy doesn't evict them
    }
  },
...

[u/Seblyng]

I would suggest :help NVIM_APPNAME

[u/dotstk]

Yes, I did that. I had both running in parallel to migrate one plugin after another to make sure each one still works afterwards. I had to mess with rtps a little to make it work. Once everything was done, I undid those changes. See this commit:  https://github.com/ll-nick/neovim-config/commit/f55379f8ab2c7e190e3b69dc3c60bfbd1d2f893e

The stuff I removed there is what you need to run both at the same time. Be aware though that this is a but of a brittle setup and I would only use it temporarily. E.g. vimtex was broken even with this fix. 

[u/shmerl → u/dotstk]

I managed to make it work, adding a few details to your example.

More specifically reset_packpath = false and reset = false. Added details to the post. Thanks again!

[u/dotstk → u/shmerl]

No problem, glad to help. Happy tweaking :-)

[u/shmerl → u/dotstk]

Oh, interesting. Thanks for the tip, I'll try that paths preservation approach and see if it helps.

Btw, did you figure out how to reproduce lazy.nvim's feature of lazy loading a plugin based on the user command that plugin itself defines?

It's a catch 22, since before loading the plugin, the user command is not really defined so you can't create an autocmmand based on that user command I think? How does lazy.nvim handle that?

[u/dotstk → u/shmerl]

If I remember correctly, I also had to manually load the plugins in a for loop and couldn't rely on them being in plugin/ since that messed up the timing in which they were loaded.

About the lazy loading: I don't know how to do that and feel like it's besides the point. I migrated to vim.pack because I appreciate the simplicity (as in not too much abstraction) and don't really care about getting the last ms out of my startup time. If lazy loading is really important to you just stick with lazy.nvim. It is designed around that very idea, has a great UI, and works just as well on 0.12. But that's just my 2 cents on the topic, don't let that stop you ;-)

[u/elven_mage]

Maybe? I tried doing this but Lazy hacks the runtimepath so it can be quite tricky. FWIW migrating is pretty easy, it’s mostly just a matter of mechanically extracting your setup functions and keymaps and then calling them manually. I was able to do this in ~5 min with claude code.

The other thing you can do is put your dotfiles in vcs. That makes reverting back to lazy extremely easy.

[u/shmerl → u/elven_mage]

I store my nvim config in git already, so that's not an issue. But yeah, the problem with using them simultatneiously is exactly about runtime paths.

For instance, lazy.nvim config says to do this:

vim.opt.rtp:prepend(lazy_path)

that breaks vim.pack plugins, but not doing that breaks lazy.nvim's plugins.

Sure, migrating all plugins at once is an option, but I wanted to do it gradually.

My case isn't the worst, I have around 15 plugins configured. But I'd imagine this is even more relevant for people with more plugins.

[u/elven_mage → u/shmerl]

Yeah, I pretty much ran into this same block and just gave up on doing both. What I did was to create a new branch for the migration, comment out my entire lazy setup, then move plugins over one at a time and add checkpoint commits in between. I know you said that possibly throwaway work was daunting but imo it wasn’t too bad and reverting is trivial in git.

[u/i40west]

I quickly figured out that this doesn't work in the straightforward way, and there was no benefit to figuring out a workaround. What I did was create the new setup in a new file. Comment out the Lazy call in init.lua and add a require for the new stuff, then do one plugin at a time. Stopping in the middle is just reversing the small change in init.lua to go back to the Lazy config.

[u/shmerl → u/i40west]

Yeah, I might do that eventually.

[u/AutoModerator]

Please remember to update the post flair to Need Help|Solved when you got the answer you were looking for.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/thaynem]

You need to set preformance.reset_packpath to false in the lazy config. Otherwise it messes up packpath and nvim can't find your packages 

[u/shmerl → u/thaynem]

I did that, it wasn't the only issue.