Repository: neovim
Issue: Create a package index
Labels: plugin,distribution

Vim users have vim.org as a package index to some extent, and then a bunch of random repos on Github, but I think we can do better.

I'd like to create something similar to Vim Awesome, but host it at packages.neovim.io or plugins.neovim.io. I think that while we _could_ do this with Github Pages, it would be a better user experience to build it with something a little more robust (i.e. some server-side programming language). Obviously, this system would be open source, but we should provide the canonical version for Neovim.

I'm willing to build and host this system. I'd also like to suggest that we place one non-obtrusive ad (something like  somewhere on the page. I'd propose a 30/70 split of the proceeds from that ad - 70% going to Neovim (ideally, to help pay for more full time work on Neovim), and 30% going to me to help recoup hosting costs (as I expect that the main instance could get fairly high traffic over time).

There would be no cost to users to use the service, and anyone would be able to set up an account and list their package. I imagine this working a bit like Packagist (for anyone familiar with the PHP world), Dockerhub (for Docker users), or npm (for Node.js users).

Basically, a user signs in with Github or Bitbucket. The application then gets a list of their repos, and they can click a button for a given repo to add that repo to the index. Depending on what the app can parse out of their repository (name of the plugin, description, dependencies, etc), there may be a second step to ask them to clarify any additional information. When they click go, we'll save the entry and add a webhook to that repository so that we're notified whenever there are new commits/tags so that we can display the appropriate information to the user.

One thing that's really important to making this service scale reasonably well is to not try to crawl through all of the Github repositories like Vim Awesome does. I think that's a massive waste of time and computing resources. It's much better to just have users add their packages and be notified when they're updated.

Since this service would also be open source, users would be able to spin up an instance of their own to host private packages if they wanted to (for instance, maybe a company has internal editor plugins that really only make sense to distribute to that company's employees). I imagine this process would look something like:
1. Install the software
2. Add a line to your vim config to include your package index
3. Use whatever package manager you use normally, and the packages included in your own index will be included in searches and whatnot.

This also opens the door to having real machine-readable dependency lists for a given plugin, and this applies to system config/supporting software, vim configuration, and what other plugins are installed. For instance, [Syntastic](https://github.com/scrooloose/syntastic#requirements) depends on having a vim with "autocmd, eval, file_in_path, modify_fname, quickfix, reltime, and user_commands" enabled. A package manager that's aware of those platform dependencies can let the user know when they install the package that they're missing something important. [clang_complete](https://github.com/rip-rip/clang_complete) depends on having `clang` installed on the system. And [Unite](https://github.com/Shougo/unite.vim) used to depend on [vimproc](https://github.com/Shougo/vimproc.vim), so a package manager that was aware of that relationship could have just automatically installed vimproc when Unite was installed.

@tarruda @justinmk What do you think about having something like this as the "official" neovim plugin list? I may have asked about this before, but I can't recall.

The value I see in this is that there's one place for people to go look for packages. Discoverability of vim packages has been a pretty difficult thing for me in the past, and it ends up being very time consuming. Having one index with search, categorization, and user ratings/reviews seems like the perfect way to resolve that issue, and having it open source means that the community can help to improve it over time.