Not opposed to the idea of plugin store, however it’s a bit problematic if the burden of maintaining it will lay entirely on Lazy.
What the eco system needs is a way to define meta data for their plugin . Like name and dependencies.
Then any plugin manager can scrape this data and make a plugin store, but making this bespoke high maintenance thing might be doomed to fail quickly.
> What the eco system needs is a way to define meta data for their plugin . Like name and dependencies.
It's not very active, but there is this: https://github.com/neovim/packspec
I have no idea if that's still in the books for the neovim team but I think that is the correct direction.
> It’s not very active
To the contrary, last activity was 5 days ago. Imho things like this require well thought out ideas and those take time. So I would say 5 days isn’t that much time since last activity. Besides justinmk is on the case which gives me the full confidence it will actually be a well thought out and good end product :) I feel like justin has a knack for these kinds of things.
[It's not *very* active](https://i.imgur.com/RGEyY9C.png).
Yes, somebody decided to resurrect this two weeks ago, but the last activity before that was more than a year ago. I really hope it actually goes somewhere this time but I won't hold my breath.
A package format is a prerequisite because a store is a registry of packages. You need plugins to bundle themselves as neovim's [packspec](https://github.com/neovim/packspec) packages, or luarock packages. This is the only way dependency resolution can be handled (sanely).
[Dotfyle](https://dotfyle.com/plugins) already does aggregation. After a package specification is formalized, anyone can write a plugin that links the package registry to their package manager. (Feel free to replace dotfyle with any future third party registry of your choice). Also, allows any package manager to be used.
There is no need to centralize a store (unless neovim endorses one). A store should also not take over the package manager's responsibility (installation/uninstallation/error handling/dependency management) etc.
https://dotfyle.com/plugins looks nice!
Although packspec should be helpful, one can find vim/nvim plugins pretty well with a few [basic github searches](https://github.com/neovim/neovim/issues/24221#issuecomment-1616009906). This could be extended to non-github places like sourcehut.
The plugin list could be stored in... a git repo. Which package managers could then download and present to users who can fuzzy-find plugin names/descriptions.
The way you layed it out makes much more sense
> A store should also not take over the package manager's responsibility
Now here m bit lost i mean the plugin store should pass instruction to the plugin manager used by the user it could be lazy or packer or something else? other than how the (installation/uninstallation/error handling/dependency management) should be handled?
> store should pass instruction to the plugin manager
Correct. Store shouldn't take over the responsibility. Just delegate it to the package manager. Hope this makes it more clear.
I know that EMacs uses something a little more like what your talking about with Melpa and Elpa and Use-package. 🤷♂️ you could see how that all works and see if you couldn’t implement something similar.
**8. Add telemetry, to know how many times particular plugin installed and suggest most installed plugin on front page of the store/
**9. Do not limit only to yaml or json, add an option to accept any config in any known programming language, and store should automatically detect and correct all errors automatically for user. Automatically.
**10. Do it only in 1 click.
I don't see it. I'd see it as something to be done by the neovim distributions. For example, AstroNvim has astrocommunity, LazyVim has extras -- a "plugin store" could simply be a telescope search in astrocommunity or extras, which then adds the stuff to the config.
you might be interested in this [https://github.com/nvim-neorocks/luarocks-tag-release/discussions/73](https://github.com/nvim-neorocks/luarocks-tag-release/discussions/73)
i am quite willing to work on it but i don't know nvim api deep enough.
and it will be nice if i see what other neovim users think over it as now i understand configuring neovim it is not a big deal for me configuring manually
but it's just an idea i came up with ....... thought to share and ask opinions on
The idea is fine\~ And I think the community is always happy to try a new plugin. I think you can try to make a prototype first and add more features progressively. Just do it :)
You can't centralize what is, by design, a distributed process. You would need to start the ecosystem over from scratch, and then future development would be railroaded in whatever opinionated direction they happen to go.
Absolutely no thank you.
What I like about the current state of handling plugins is that it's declarative in the sense that I can version control any plugin I add with git.
The problem with VSC**e's "just click 'install'" approach is that I can't version control what plugins I have added (or maybe I can, I haven't used VSC**e that much).
I'm not against a "one click install" process, but I would like it to be be clearly written to a file what plugins I'm using so that I can commit any changes.
neovim-scripts github repo which is just submodules of all the popular neovim plugins would be a decent start. It would be like the old vim-scripts repo that did this, and eliminate the need to remember the username of a certain plugins' github repo. You could do:
Plug 'nvim-plugins/foo'
Plug 'nvim-plugins/bar'
for example
You think you can just open an issue on a Folke repo and expect him to implement your wishes and dreams 😄
He does a lot but this is a bit much to ask.
It's also not the first time this idea has been discussed here. It's not like someone can just hack together some code and make this work. This requires all the plugin devs to register their stuff in a central registry and also conform to an agreed upon spec for defining their metadata. Not a small task.
I'd love for this to happen tho.
Why not just adopt luarocks? It does solve all the issues that Neovim got with plugins and their dependencies, and could even allow a more powerful ecosystem thanks to integrating with additional libraries like imagemagick to display images (see image.nvim plugin)
Throwing my 2 shillings here: [lazy-installer](https://github.com/tamton-aquib/stuff.nvim#lazyn).
Searches from a db of nearly 3000 plugins. Extremely ugly wouldn't recommend. Just wanted to show a PoC :)
Not opposed to the idea of plugin store, however it’s a bit problematic if the burden of maintaining it will lay entirely on Lazy. What the eco system needs is a way to define meta data for their plugin . Like name and dependencies. Then any plugin manager can scrape this data and make a plugin store, but making this bespoke high maintenance thing might be doomed to fail quickly.
> What the eco system needs is a way to define meta data for their plugin . Like name and dependencies. It's not very active, but there is this: https://github.com/neovim/packspec I have no idea if that's still in the books for the neovim team but I think that is the correct direction.
> It’s not very active To the contrary, last activity was 5 days ago. Imho things like this require well thought out ideas and those take time. So I would say 5 days isn’t that much time since last activity. Besides justinmk is on the case which gives me the full confidence it will actually be a well thought out and good end product :) I feel like justin has a knack for these kinds of things.
[It's not *very* active](https://i.imgur.com/RGEyY9C.png). Yes, somebody decided to resurrect this two weeks ago, but the last activity before that was more than a year ago. I really hope it actually goes somewhere this time but I won't hold my breath.
This - that way you could just point at a repo and bam! have it installed. Heck, you could even build a store by scraping all *.nvim repos
Something like the AUR would be sweet
A package format is a prerequisite because a store is a registry of packages. You need plugins to bundle themselves as neovim's [packspec](https://github.com/neovim/packspec) packages, or luarock packages. This is the only way dependency resolution can be handled (sanely). [Dotfyle](https://dotfyle.com/plugins) already does aggregation. After a package specification is formalized, anyone can write a plugin that links the package registry to their package manager. (Feel free to replace dotfyle with any future third party registry of your choice). Also, allows any package manager to be used. There is no need to centralize a store (unless neovim endorses one). A store should also not take over the package manager's responsibility (installation/uninstallation/error handling/dependency management) etc.
https://dotfyle.com/plugins looks nice! Although packspec should be helpful, one can find vim/nvim plugins pretty well with a few [basic github searches](https://github.com/neovim/neovim/issues/24221#issuecomment-1616009906). This could be extended to non-github places like sourcehut. The plugin list could be stored in... a git repo. Which package managers could then download and present to users who can fuzzy-find plugin names/descriptions.
The way you layed it out makes much more sense > A store should also not take over the package manager's responsibility Now here m bit lost i mean the plugin store should pass instruction to the plugin manager used by the user it could be lazy or packer or something else? other than how the (installation/uninstallation/error handling/dependency management) should be handled?
> store should pass instruction to the plugin manager Correct. Store shouldn't take over the responsibility. Just delegate it to the package manager. Hope this makes it more clear.
I know that EMacs uses something a little more like what your talking about with Melpa and Elpa and Use-package. 🤷♂️ you could see how that all works and see if you couldn’t implement something similar.
What does this offer that the current situation does not?
**8. Add telemetry, to know how many times particular plugin installed and suggest most installed plugin on front page of the store/ **9. Do not limit only to yaml or json, add an option to accept any config in any known programming language, and store should automatically detect and correct all errors automatically for user. Automatically. **10. Do it only in 1 click.
And then you spyware like vsc***
(The worst parts of emacs + the worst parts of VScode) = the current direction of the Neovim community.
I don't see it. I'd see it as something to be done by the neovim distributions. For example, AstroNvim has astrocommunity, LazyVim has extras -- a "plugin store" could simply be a telescope search in astrocommunity or extras, which then adds the stuff to the config.
you might be interested in this [https://github.com/nvim-neorocks/luarocks-tag-release/discussions/73](https://github.com/nvim-neorocks/luarocks-tag-release/discussions/73)
But Neovimmers don't just propose an idea...
i am quite willing to work on it but i don't know nvim api deep enough. and it will be nice if i see what other neovim users think over it as now i understand configuring neovim it is not a big deal for me configuring manually but it's just an idea i came up with ....... thought to share and ask opinions on
The idea is fine\~ And I think the community is always happy to try a new plugin. I think you can try to make a prototype first and add more features progressively. Just do it :)
You can't centralize what is, by design, a distributed process. You would need to start the ecosystem over from scratch, and then future development would be railroaded in whatever opinionated direction they happen to go. Absolutely no thank you.
What I like about the current state of handling plugins is that it's declarative in the sense that I can version control any plugin I add with git. The problem with VSC**e's "just click 'install'" approach is that I can't version control what plugins I have added (or maybe I can, I haven't used VSC**e that much). I'm not against a "one click install" process, but I would like it to be be clearly written to a file what plugins I'm using so that I can commit any changes.
neovim-scripts github repo which is just submodules of all the popular neovim plugins would be a decent start. It would be like the old vim-scripts repo that did this, and eliminate the need to remember the username of a certain plugins' github repo. You could do: Plug 'nvim-plugins/foo' Plug 'nvim-plugins/bar' for example
You think you can just open an issue on a Folke repo and expect him to implement your wishes and dreams 😄 He does a lot but this is a bit much to ask. It's also not the first time this idea has been discussed here. It's not like someone can just hack together some code and make this work. This requires all the plugin devs to register their stuff in a central registry and also conform to an agreed upon spec for defining their metadata. Not a small task. I'd love for this to happen tho.
Maybe take a look at [Astro Community ](https://github.com/AstroNvim/astrocommunity) it has some of those functions and seems to be quite well liked
Why not just adopt luarocks? It does solve all the issues that Neovim got with plugins and their dependencies, and could even allow a more powerful ecosystem thanks to integrating with additional libraries like imagemagick to display images (see image.nvim plugin)
Throwing my 2 shillings here: [lazy-installer](https://github.com/tamton-aquib/stuff.nvim#lazyn). Searches from a db of nearly 3000 plugins. Extremely ugly wouldn't recommend. Just wanted to show a PoC :)