Split HLS plugins into internal libraries

[isovector]

While working through #391, and now attempting to do followup work, I'm continually running into issues of project structure. Today, HLS consists of a small internal library providing common functionality to plugins, and then one monolithic executable providing all of the plugins.

Due to the inaccessibility of the source code in cabal executables, the only sort of testing that can be done against the HLS exe is at the integration-level. And this testing must be mediated via LSP, aggressively limiting it's usefulness for any sort of unit test of internal-facing behavior.

Instead, I'd suggest moving plugins to internal libraries which eventually get linked by the exe. This would allow for the code to be reused in tests, and improve incremental build times for everyone.

[alanz]

FYI that is the next step as envisioned in #164

[isovector]

Excellent. Is there a timeline on #164? I'm willing to throw some elbow grease at it if necessary.

[alanz]

The goal is to have it done before we release the rest to hackage. And no blockers, just not got to yet. I suggest pinging @jneira and @fendor to coordinate any activity though.

[jneira]

I am afraid that we had issues with cabal private libs in the past:

• Due to a nasty cabal bug, the presence of private libs drives to cabal store corruption. The unique workaround is wipe out the entire store or the offending packages inside and run cabal-store-check --repair
• The stack explicit cradle cant load private libs: stack cradle fails to load private lib #114

We had a private lib and we converted it to a common stanza to avoid those problems: #136.

For the hlint plugin that must live in its own lib to being even buildable (due to ghc-lib) we opted to create a subpackage, with its own .cabal file: #166 (comment)

[jneira]

I would separate plugins one by one in their own subpackages, if we consider that it would give us something in return.
Bigger plugins, like tactic are good candidates to live in its own package, but simpler ones maybe will not need it.

[isovector]

@jneira how do you suggest I move forward in that case?

[jneira]

Well, as first step i would move the tactic plugin in its own subpackage (hls-tactic-plugin?) cause it will improve its development process and the extra maintaining effort would worth it for sure.
We did it for the hlint plugin, although it is not merged yet: https://github.com/jneira/haskell-language-server/tree/hlint-plugin-ghc-lib/plugins/hls-hlint-plugin.

[alanz]

@jneira part of the context is refactoring the build etc process to enable testing of subcomponents. Will this do that?

[jneira]

Mmm, good question, i supposed the advantages of having a private lib are the same as having a subpackage. The plugin could have its own (unit?) test suite or a hls test suite could have the plugin as dependency.

[isovector]

We tried using an internal library but as anticipated, none of the tooling could handle it. @TOTBWF and I are running into some extremely subtle bugs in tactics right now that don't show up outside of HLS. Being unable to write tests is extremely painful --- how can we move forward on this issue?

[jneira]

@isovector could split the plugin in its own subpackage as commented above help? It is an almost mechanic change

[fendor]

I am in favour of splitting them into sub-packages. I think this will help with future work, too, e.g. when we have compile-time plugin composition.