wishlist
wishlist copied to clipboard
nvim-lua
The One Plugin Manager
What?
Summarize the plugin you'd like to see exist. In a few sentences, what's your idea?
I want vim-plug but in lua. The syntax should be horrifyingly obvious, the code should be simple, it should run instantly, use the modern bells and whistles that were recently bestowed upon us (but only the bits it needs), and it should gently encourage the user to organize things in a simple and effective manner. Most importantly, it should be the Obvious Answer™ to the question “what do I use to manage my plugins?”, with a name like plugins.nvim.
Why?
What should this plugin provide? What problems does it solve?
In the good/bad old days, you were happy to use Pathogen on Vim. Then maybe you moved to Vim-Plug and used that for a while. Maybe you used Dein or something else. Maybe not. Now Vim comes with “out of the box” package management, and there are five thousand different plugin (package? what’s the difference? what’s in a name?) managers from which to choose from with no Obvious Answer™.
I don’t want to think about my plugin manager. Do you? Do neovim newcomers?
Potential existing implementations:
Are there any existing plugins (Lua, Vimscript, or remote) that come close to your idea?
Too many – that’s the problem. There are the old kids on the block like https://github.com/junegunn/vim-plug, then a gazillion other written in every possible language you can think of. There are some more recent that use the (relatively) new package capabilities like https://github.com/k-takata/minpac or https://github.com/kristijanhusak/vim-packager.
Closest to what I have in mind is probably https://github.com/wbthomason/packer.nvim. Maybe. I don’t know. To know I’d have to think about plugin managers, which is what I’m trying to avoid in the first place.
Potential pitfalls:
Are there any challenges you're aware of to making the plugin you're proposing?
There may not be an Obvious Answer™ because people want fundamentally different things. That’s a cowardly excuse.
Also it would be good for the community I think to suggest a package description that would list dependencies, and have "The One" package manager handle dependencies for you :)
Not to make you think about plugin managers too much (a horrible fate, I agree), but can you elaborate on how packer differs from what you want?
Not to make you think about plugin managers too much (a horrible fate, I agree), but can you elaborate on how
packerdiffers from what you want?
To be fair I’ve been tweaking around with packer since yesterday and it’s really nice. Half of my wish really is “can we stop it with the 10,000 competing options with no clear winner?” If packer turns out to be the wish-granter, I suspect we’ll be alright.
What I don’t like about it probably has little to do with packer itself (it’s not you, it’s me). Right now I’m annoyed at having to go through the PackerCompile step, but I expect I’ll stop minding so much once I have adapted to the workflow. How much is it by design, vs. because of current neovim limitations that we can expect to see gone in the ‘short term’ (e.g., https://github.com/neovim/neovim/issues/7895)? In other words, is it a long term fixture, or a temporary workaround?
The other thing that frustrates me right now is that lualand is needlessly hard to figure out. Simultaneously to trying packer, I’ve been trying to quit my bad habit of having random bits of configuration interpersed in my plugin file. It’s now been [unavowably long] that I’ve been trying to please vimtex, who’s apparently peculiar about having g:tex_flavor set early. A cargo cult approach leads me to think that I could write
use { 'lervag/vimtex' , config = 'require("vimtex")' }
to load the configuration in lua/whatever/vimtex.lua, but no, it has to be lua/vimtex.lua or lua/vimtex/init.lua. Why? (also why is vimtex complaining if I set g:tex_flavor too late? but that’s a question for vimtex.)
Anyhow. I’ll be fine, but I think some more hand holding would be beneficial. I can help if needed, once I get a grip of how things work.
PackerCompile is mostly by design (I wanted to minimize load time for complex lazy-loading by pre-generating code for that logic), but I am actively looking for ways to remove the manual compile step. It's worth noting that PackerSync runs the compile step for you, so it can make the process a bit smoother.
The lua path stuff is more fundamental to Neovim's integration of Lua, though. For your example, you could modify package.path to include other directories, but that requires (1) you to know about this option and (2) a bit of manual finagling to get right.
I admit that packer can be pretty complex, and I would like to find ways to make it easier to use. If you have suggestions/complaints/etc., please feel free to add issues on the packer repo!
@wbthomason My suggestions would be breaking changes to simplify the design.
-- Load on a combination of conditions: specific filetypes or commands
-- Also run code after load (see the "config" key)
You can do this in init.lua as well. Plugins should communicate with a specialised format, what kind of setup they recommend.
Another person could provide a settings conflict resolution tool and you would not need to deal with calling scripts.
-- Plugins can have dependencies on other plugins
UPDATE: Dependencies are all explicit. That should be fine and useful to automatically clean clutter.
-- Plugins can have post-install/update hooks
How do you align changes in the install/update hooks with the package requirements though? Namely you have wrong/inaccurate procedures for hooks and hook changes after package updates to handle.
-- You can specify multiple plugins in a single call
Non-Linear control flow should be avoided, if possible. What was the reason for this?
UPDATE: all things super useful to try out packages. Just put all the stuff in a line and comment it in and out.
As an author of one of these mentioned package managers (https://github.com/kristijanhusak/vim-packager), I completely agree with author.
I wrote mine to leverage built in packages feature, and to avoid pulling in monster vim-plug file.
Having this in lua with all those features would be neat.
Even having this as part of the neovim core would be great IMO. Few people (including myself) could contribute to that part of the neovim to make it as best as possible.
I would then just recommend neovim users of my package manager to use the built in one.
@wbthomason What was the reason to enable -- You can specify multiple plugins in a single call ?
So far I have never used this and moved almost everything to an init.lua.
Would removing this simplify your code considerably?
raises hand I'm using it extensively. :) Also it looks like it doesn't complicate the code too much—it's basically just 'is arg1 a list-table with more than one entry? if yes, rerun packer.use() on each of them'.
Basically this. I find it nice for grouping thematically similar plugins that are not quite dependencies.
Basically this. I find it nice for grouping thematically similar plugins that are not quite dependencies.
I definitely appreciate grouping my plugins like this
Speaking of grouping plugins, I’ve been wondering about whether one might want to reflect such grouping in the folder structure of the Vim packages:
.local/share/pack
├── colorschemes
└── version_control
…
has anyone already thought of the pros/cons of such a thing?
"I want vim-plug but in lua."
Have you checked out Paq?
https://github.com/savq/paq-nvim
It is unlikely that it converges to 1 way of doing things, because people prefer different complexity and different number of times "to update plugins" and "review the code".
I dont think there will be one solution for the simple approaches, because there are different options how to vendor dependencies (bare download, simple git pull --rebase/--norebase, git pull .. (but with lock files), flakes, patches or even doing it manually and hooking up a few scripts).
More complex plugin managers may implement dependency resolution (pre/lazy)loading and more fancy stuff like disabling plugins, integrating luarocks, snapshots + rollbacks etc. Packer.nvim supports most of these, but it becomes extremely tricky to properly test the edge cases with more complexity. Nix approaches have the same problem and on top flakes are still unstable.
Unfortunately there is no blog post to reflect design decisions of packer, so I can not tell nothing about the design of https://github.com/ii14/neopm and if it can remove many problems of packers by design etc.
What I would like most is, if plugin managers would advertise strict versioning like providing 2 columns for repo + git hash and this plugin "just pulls everything". After every update, unless opted out, the git hashes are versioned so you can bisect or restore trivially. This would make it trivial to vendor stuff yourself (copy-paste the repo and do git checkout to last known working version) and reproduce issues like what is possible in nix flake configurations that store the accurate source version in the lockfile.
Does meta plugin manager help for you here? I wrote my own extensible plugin manager wrap on top of vim-plug that soon will be supporting switching between different plugin managers (with certain limitations) for easier migration/transition.
The reason it was born is that I would like to have a unified plugin management API that would talk to the plugin manager so I can control how plugin will be loaded/configured without a need to rewritten the whole configuration structure (as I used quite a number of plugins). All of the plugin implementation work are mostly out of my own use case here.
