Only reason I switched was I was redoing my neovim config in lua. Almost all the lsp examples are in lua and most lua plugins showed packer config examples. So I went with the kids path of least resistance and used what seemed most popular at the time.
When an ecosystem is new there is a lot of design space to explore. No one knows what the best ideas will be - the only way to find them is to try lots of things. After a while it becomes clearer what the good ideas are, and things settle down. That happened in Javascript when React and Vue became popular. You didn’t see a new application framework every month anymore - at least not ones that got a lot of adoption. Exploration shifted to stuff like state-management libraries to use within React. Of course the search for better ideas never stops completely…
I’ve been updating my plugin managers for over ten years now. Would be nice if neovim just bundled a default plugin manager you could use and all the examples could use.
Vim’s built-in packadd feature is available on Nvim too – https://neovim.io/doc/user/repeat.html#packages ; and as long as there’s a folder named ‘lua’ inside the package folder (e.g. $xdg_data_home/nvim/pack/the_package_name/start/), it’s on lua’s path/cpath as well.
One annoyance is making sure your lua modules can find luarocks you may have installed elsewhere. The easiest way to do that is to start nvim with an env LUA_{C,}PATH prefix pointing at the right folders.
The config examples for nvim plugins are just lua tables – as long as the user has a clear idea as to how they’re sourced alongside other stuff on the lua paths, it’s not too big of a deal if the examples presuppose a particular manager. Lua isn’t the prettiest language to read, though; and some of its syntactical ‘shortcuts’ can get annoying for people just starting out.
This happens all the time with new projects. And yes, I know neovim is not that new anymore, but its development is still very active and a lot of things change, so the whole ecosystem around it will change. This will stabilize in a few years and we’ll have fewer and more stable plugin/package managers.
This is one thing I hate about Neovim. One year, Packer is what everyone uses, next year it’s deprecated. It’s like with JavaScript libraries.
I don’t mind… It’s innovation. Lazy is arguably much better than packer.
Neovim is much better than vim as well.
I just switched to packer 3 months ago from Plug.
I’m curious, why did you switch from plug? I keep seeing new plugin managers pop up but plug has been solid for years for me.
Only reason I switched was I was redoing my neovim config in lua. Almost all the lsp examples are in lua and most lua plugins showed packer config examples. So I went with the kids path of least resistance and used what seemed most popular at the time.
deleted by creator
When an ecosystem is new there is a lot of design space to explore. No one knows what the best ideas will be - the only way to find them is to try lots of things. After a while it becomes clearer what the good ideas are, and things settle down. That happened in Javascript when React and Vue became popular. You didn’t see a new application framework every month anymore - at least not ones that got a lot of adoption. Exploration shifted to stuff like state-management libraries to use within React. Of course the search for better ideas never stops completely…
I’ve been updating my plugin managers for over ten years now. Would be nice if neovim just bundled a default plugin manager you could use and all the examples could use.
Vim’s built-in packadd feature is available on Nvim too – https://neovim.io/doc/user/repeat.html#packages ; and as long as there’s a folder named ‘lua’ inside the package folder (e.g. $xdg_data_home/nvim/pack/the_package_name/start/), it’s on lua’s path/cpath as well.
One annoyance is making sure your lua modules can find luarocks you may have installed elsewhere. The easiest way to do that is to start nvim with an env LUA_{C,}PATH prefix pointing at the right folders.
The config examples for nvim plugins are just lua tables – as long as the user has a clear idea as to how they’re sourced alongside other stuff on the lua paths, it’s not too big of a deal if the examples presuppose a particular manager. Lua isn’t the prettiest language to read, though; and some of its syntactical ‘shortcuts’ can get annoying for people just starting out.
This happens all the time with new projects. And yes, I know neovim is not that new anymore, but its development is still very active and a lot of things change, so the whole ecosystem around it will change. This will stabilize in a few years and we’ll have fewer and more stable plugin/package managers.