A Guide to vim.pack (Neovim built-in plugin manager)
23 points by echasnovski
23 points by echasnovski
Evgeni is a genuinely heroic contributor to Neovim and its larger environment, and I am very sure that vim.pack will make life easier for tons of people. I'm also sure that this post will help people use vim.pack better. Thanks for writing vim.pack and this.
That said, I have one personal observation, and I wonder if it rings true for anyone else. After years of different strategies for handling plugins in Vim and Neovim, I decided that I was happier to use a plugin manager that was not built into the editor. (I decided this before vim.pack existed, so it has nothing to do with how vim.pack is designed.) Here's my reasoning: when I open the editor, I want to edit text, I don't want to manage or update plugins then (or there). If, for example a plugin that I rely on a lot (say nvim-snippets) has just updated, then I would very likely need to restart the editor and maybe even update my configuration before restarting. I'd rather that be separate from normal editing sessions. What I ended up doing for a long time was writing a script to use Neovim in headless mode to invoke paq-nvim to update plugins. Eventually, I separated things even further and wrote a small Go program to read a config file and handle my plugins. As a bonus for me, it works equally well for Vim or Neovim because all it does is install, update, or delete Git repositories from specific places on disk. I use both, so I create multiple configs and invoke it as pluggo --config=<vim-config> or pluggo --config=<neovim-config>. (After I'd already written this, I discovered Joey Hess's myrepos, which does pretty much what I needed. Oh well.)
I could come up with a workflow where I use vim.pack (or paq-nvim or whatever) in a way that separates it from normal editing sessions, but in the end I prefer to more cleanly separate "dealing with a bunch of Git repos" from editing.
Here's my reasoning: when I open the editor, I want to edit text, I don't want to manage or update plugins then (or there).
I would also not want that. It is an example of plugin autoupdate which I don't really get behind. In my mind, updating plugins is better as a result of explicit decision to update them. Ideally with some mental and temporal capacity to manage possible breaking changes. I usually do that in the morning of a day off.
Eventually, I separated things even further and wrote a small Go program to read a config file and handle my plugins.
Writing things that are tailored to one's needs/workflow is completely fine and in the spirit of Vim/Neovim. "If it works for you, use it; keep an open eye and mind for something that can improve it" is usually my advice in this sort of situations.
My personal path with Vim/Neovim plugins was vim-plug (updating looked cool) -> Git submodules (when started my pluginless journey) -> mini.deps (when decided to write a plugin manager for upstream) -> vim.pack (when that got merged upstream and was relatively stable). In the end, all these options are "dealing with a bunch of Git repos", just the the UI (both visual and functional) changes from command line to be inside the editor.
In the end, all these options are "dealing with a bunch of Git repos", just the the UI (both visual and functional) changes from command line to be inside the editor.
Thanks for the response. To clarify one thing: most of the options that handle Git repos "inside the editor" hardcode the locations that repos are stored, correct? (E.g., I think that vim.pack uses <standard-path>/site/pack/core/opt.) One important advantage (for me at least) of completely separating the editor from the tool that handles the Git repos is that I have more control over where repositories end up. I can have different config files for Vim and Neovim and I can choose different sub-paths per-repo. (Once I started to see things this way and discovered myrepos, my thinking changed from "I want a tool to handle Neovim and Vim plugins" to "I want a tool to perform batches of Git operations in parallel.")
To clarify one thing: most of the options that handle Git repos "inside the editor" hardcode the locations that repos are stored, correct?
Sure, but mostly because it is easier that way: no need to mess around with 'runtimepath' (in what its part exactly to add the plugin path), no need to implement custom logic of adding a plugin (like sourcing 'plugin/' and 'ftdetect' directories). Just reuse what is already present in both Vim and Neovim: <standard-path>/site is already in 'runtimepath', plugin packages concept ('pack/<name>/opt'), and :packadd.
There are plugin managers which implement everything from scratch and the location of where to store repos is customizable. That is fine also.
Sorry, but I wasn't clear. I also follow the runtimepath conventions when using my tool for Vim or Neovim. My point is that by including the tool in an editor and then hardcoding it to work with exactly the paths for that editor, the tool becomes less general. It absolutely makes sense for a tool built into Vim or Neovim to hardcode the directories, as you say, but that makes it less of a generic tool for "dealing with a bunch of Git repos."
I'm not trying to tell you something you don't know or criticize any of the choices you made (or any Vim/Neovim plugin manager makes). I'm just explaining in a different way why I ended up preferring a tool outside of the editor: I can use it in multiple contexts, many of which have nothing to do with editors or plugins.
It absolutely makes sense for a tool built into Vim or Neovim to hardcode the directories, as you say, but that makes it less of a generic tool for "dealing with a bunch of Git repos."
Yes, of course. But at its core it is still "deal with a bunch of Git repos", just with a UI and default choices tailored to the editor. More general tools are also fine, they just (usually) don't provide a more ubiquitous "my config plus Git is all I need to manage my setup".
I'm not trying to tell you something you don't know or criticize any of the choices you made (or any Vim/Neovim plugin manager makes).
There was never a doubt. Just always happy discuss interesting ideas and nuances :)
My needs have been simple and I have always been confused by the plugin managers for Vim and Neovim.
I much prefer the ability to just drop code into the ../pack/.. directory.
I much prefer the ability to just drop code into the ../pack/.. directory.
How do you update that code? A long time ago, I described myself as "not using a plugin manager" in a Reddit discussion about Vim. Then I mentioned the shell script I had written to update my Vim plugins. Someone came along and correctly replied that the shell script was my plugin manager.
I don't :) My needs are extremely simple.
I used to have some eye candy stuff but I got rid of it.
If something breaks, I'll do a git pull, or just overwrite with the latest release.
If a distribution packages a plugin, should that be installed into an “opt” path or a “start” path? What would be folks’s expectations?
I would say that it depends on 1) plugin; 2) packager's intent; 3) user preferences. The core difference is that "start" is always loaded during startup, while "opt" needs explicit "opt-in loading".
My personal preference would have been to only have "opt" plugins and allow (or in different perspective - require) user to opt-in. But for more opinionated distribution using "start" might be a better trade off.
Thanks. The reason I was asking was I recently saw a request for a mentorship of a plugin package for Debian. I did a brief review, and I believe it installed into the start directory. I think that means any user of vim on a system with this package would have the plug-in enabled by default. The plug-in was vim-vinegar for what it’s worth. I was pondering what a sensible default would be for Debian. I’m not part of the Debian vim team, and they’ve probably thought about this already.
I did a brief review, and I believe it installed into the start directory. I think that means any user of vim on a system with this package would have the plug-in enabled by default.
Yes. If it is installed in start, it is enabled by default.
I was pondering what a sensible default would be for Debian.
It looks like Debian does a Debian-specific thing (often but not always—see below): https://vi.stackexchange.com/questions/38485/what-does-runtime-debian-vim-actually-do/38489#38489. If I understand the post correctly, Debian (often but not always—see below) puts Vim plugins in /var/lib/vim/addons and adds that directory to Vim's runtimepath variable when it builds Vim. (If a user installs those plugins, they are probably enabled by default when the user starts Vim.)
On the other hand, Debian also provides a vim-scripts package. That puts scripts into /usr/share/vimscripts/<packagename>. That package specifies, "All of the addons are installed as "optional" Vim packages. They can be enabled by adding "packadd! <addon>" (e.g., "packadd! AlignPlugin") to the vimrc."
And, finally, there are some completely different things. E.g., vim-python-jedi goes into /usr/share/vim-python-jedi, and you have to use "packadd! python-jedi" to load it.
¯\(ツ)/¯
PS In my experience, "enabled by default" is not a problem for (most) Vim plugins because the autoload mechanism provides lazy-loading as a default.
Here’s my minimal nvim config using vim.pack. It dramatically simplified my plugin management: https://erock-git-dotfiles.pgs.sh/tree/main/item/dot_config/nvim/init.lua.html
Of course it’s all for nothing as I switched to kakoune. But every once in awhile I just stare at it.