Merge plugins into the HLS package

[michaelpj]

This is a POC for merging all the plugin packages into the HLS package, as discussed in #3556.

I just did the first two plugins alphabetically to show what it looks like, it's pretty mechanical.

To reiterate, the advantages are:

• Fewer packages to upload
• Less repeated metadata
• Fewer versions
• Ability to use common stanzas to e.g. have the same set of warnings everywhere (I would do this as a follow up if we decide to go this route)

Things seem to still work fine. The main annoyances are:

• Can't cd into a plugin directory and cabal build/cabal test
• Can't cabal test <plugin-name>, instead need cabal test <plugin-name>-tests

I think overall it's still going to be a pretty big improvement

[soulomoon]

One huge draw back is that it prevent us from working on a single plugin along opening just the plugin dir.
From developing perspective, working on a relatively smaller code base is much easier.

I am wondering is there a workaround for this?

[michaelpj]

I don't think it does? You can still just build the component for the plugin and it won't build anything else.

[soulomoon]

But we can no longer open an single editor containing just one plugin dir and get hls support 🤔

[michaelpj]

I don't see why not? We do support single components of packages just fine? And it'll be better as the multi-component stuff rolls out (but that's already bad if you try to edit multiple packages today)

[soulomoon]

I don't see why not? We do support single components of packages just fine? And it'll be better as the multi-component stuff rolls out (but that's already bad if you try to edit multiple packages today)

Thanx for clearing out my concern on this.

[michaelpj]

Another downside: stack supports building packages with internal libraries (the CI run succeeded!), but it doesn't do per-component builds, so the dev experience using stack will probably suck. I'm not sure how much we care about that these days 🤷

[michaelpj]

No longer a POC!

There is still plenty to do here with cleaning up the now rather monolithic cabal file, making better use of common stanzas etc, but I'm keen to land this before too long since it's very conflict-y.

[michaelpj]

cc @fendor @wz1000 as discussed

[michaelpj]

Follow up todos:

• Make all components which condition on pedantic use the common stanza for that
• Add a common stanza for default-language
• Maybe merge in some more packages. I think only hls-test-utils, everything else is a dependency of ghcide and so needs to stay out for now.
• Maybe try and organize the cabal file to be a bit more navigable

[jhrcek]

I like this approach more than the previous.
Few nitpicks about ghc-options - warnings, but I will work on those anyway in followup PRs, so feel free to ignore.

[jhrcek]

Can be removed - is now in common warnings.

[jhrcek]

You can import common warnings for this lib and remove this.

[michaelpj]

It was tasty-rerun, turning it off makes the tests run. I don't know whether it's doing something dodgy, but it seems to be orthogonal to this PR at least.

Figured out the issue

[smunix]

@michaelpj - it looks like this change broke nix rpath setting for plugins internal libraries. It fails during the install_phase as it finds references to the /build/ directory. Has 2.7.0.0 been installed successfully with nix at all?

[michaelpj]

That seems like a question for the Nix Haskell folks? It builds with cabal, so if it doesn't build with the Nix setup then that's a bug in the Nix setup, I think.