Consider packaging HLS as a single cabal package with multiple public libraries #3556
Labels
old_type: meta
Planing and organizing other issues
status: in discussion
Not actionable, because discussion is still ongoing or there's no decision yet
type: enhancement
New feature or request
Today, HLS consists of 37 packages. This is a huge pain to maintain and release, especially since we currently don't version them all identically. We almost always have issues with the Hackage release where some of the bounds aren't correct.
However, in reality they are all tested and built together by the HLS developers, and while in principle you can mix-and-match the versions of various plugins based on the bounds, it's not really something we need to support, or that brings value to users. Users mostly just want to get a HLS binary!
We do also have some users who build custom LSP systems using bits of HLS, notably SigmaIDE.
That suggests that we could just package HLS as one cabal package with multiple sub-libraries. They would need to be public sub-libraries in order to still enable the SigmaIDE use case.
That would simplify our lives a lot:
The reasons not to do this are:
The uncertainty is probably the best reason not to do this. It would be good to see some successful usage of multi-libs on Hackage before we jump in.
The text was updated successfully, but these errors were encountered: