Do we need to have every plugin in its own package?

[michaelpj]

At the moment, it seems that every plugin is in its own package.

While this is nice in principle, it seems like a lot of extra work for the maintainers:

• More cabal files to maintain, versions to bump, etc.
• More packages to upload to Hackage when doing Hackage releases (this is a big one!).

But I'm not entirely sure what benefit we get from it. The main reason I can think of is that some plugins have heavy dependencies that we don't want to include unless they're asked for (e.g. the formatting plugins). But most of them are not like this.

We could retain the split into multiple plugins while still having many of the plugins exported from a single package (thus retaining the ability to e.g. turn them on and off individually). Similarly, we could retain individual test suites by having an internal library per plugin, with at test suite that depends on just that library.

Is there another big reason for splitting them up that I'm missing?

[pepeiborra]

All the shortcomings listed above are chores. Chores can be addressed easily via automation - ideally CI would detect version bumps and perform all the steps needed for a release, including checking version bounds and uploading to Hackage.

The benefit is dependency management indeed. For instance, at work we have a custom LSP server built on top of ghcide, with a handful of selected HLS plugins, limited by our stackage snapshot and the maintenance overhead of introducing version overrides.

When there are no heavy dependencies, I agree that there is no real reason to create a new package. I guess it comes down to ownership and other random factors, like finding a reasonable "home" for a plugin. For instance, the Ghcide package contains around 10 HLS plugins:

haskell-language-server/ghcide/src/Development/IDE/Plugin/HLS/GhcIde.hs

Lines 22 to 32 in a800b9d

	descriptors :: [PluginDescriptor IdeState]
	descriptors =
	[ descriptor "ghcide-hover-and-symbols",
	CodeAction.iePluginDescriptor "ghcide-code-actions-imports-exports",
	CodeAction.typeSigsPluginDescriptor "ghcide-code-actions-type-signatures",
	CodeAction.bindingsPluginDescriptor "ghcide-code-actions-bindings",
	CodeAction.fillHolePluginDescriptor "ghcide-code-actions-fill-holes",
	Completions.descriptor "ghcide-completions",
	TypeLenses.descriptor "ghcide-type-lenses",
	Notifications.descriptor "ghcide-core"
	]

[alexnaspo]

Is there a need to take any of these plugins out of ghcide?

[jneira]

Agree with the comment above, i would add:

• uniformity: if each plugin is in one package and all of them are in the same location, they are easier to discover. If we group them the criteria could differ and it will do over time almost for sure. Uniformity is good™ in general but it shines when you have to automate things (for example the hackage release mentioned above)
• the original idea was plugins could live outside the hls repo (f.e. the hlint plugin in the hlint repo). That can be done with arbitrary grouping of plugins, but the minimum division you can do is one plugin per package so it is easy to follow

[Ailrun]

I also agree on uniformity. It makes easier to traverse HLS code base itself, and may help contributors.

[michaelpj]

Fair enough. My personal experience with a codebase with lots of packages is that it's a huge pain and I always want to consolidate them, but uniformity is indeed nice :)

On the plus side, it makes the motivation strong to keep improving multi-package support ;)