Distributing plugins

[saep]

I am opening the discussion by providing three work flows on how to distribute plugins. These work flows are not mutually exclusive!

• Community repositories that contain a bunch of plugins

  This is similar to xmonad with xmonad-contrib and xmonad-extra. There is a more or less point where you can upload plugins. Each of those repositories will have some kind of criteria of what can and should be in it. Criteria can be: not too big dependencies, reviewed by n peers, tests, quality of documentation or whatever is appropriate.

  Advantages for this approach are:

  • High discoverability for plugins
  • Plugins are kept up-to-date by the maintainers of the repository and should be compatible with releases of neovim or nvim-hs.
  • Can be shipped with (linux) distributions

  Disadvantages:

  • Potentially high entry barrier for new plugins
  • Not really suited for plugins which are still changing a lot

• Git repositories cloned into $XDG_CONFIG_HOME/lib or $XDG_CONFIG_HOME/lib/Neovim (naming could be an issue)

  If neovim were to adopt the XDG basedir specification, the paths are probably different again. Anyhow, the exact location should better be based on some discussion with real arguments rather than my nightly idea which I though should be written down before I forget it.

  Advantages:

  • Low entry barrier
  • Updating to the latest version is just one pull away and hence it is well suited for plugins which are still in active development without a stable API

  Disadvantages:

  • Low discoverability (Wiki entry here could point to those repositories)
  • Naming is restricted (or something similar to plug/pathogen/vundle for haskell plugins must be implemented)
  • Restart/Recompile times for nvim-hs grow with each plugin!

• Tool-dependent repositories as a cabal package

  This means that a plugin is just a cabal package. With tool, I mean something like ide-backend.

  It's not so easy for me to clearly state advantages or disadvantages. This could easily be the same as a community repository whore plugins mainly build on top of such a tool. In any case, I think that if some plugin author choses to walk this path, she should think about the feasibility of this approach.

[saep]

I think stack solved most of these issues.

[saep]

I think the current flexibility is okay. If there are issues, we can always solve them in a future release.