housekeeping between ghcide and hls

[alanz]

ghcide is primarily a library, which is then used in both ghcide (the exe) and as a building block for hls.

This is working well, except for one minor niggle.

Over time, the amount of functionality in the ghcide/exe directory is growing. This is not shared between the applications, and requires a manual sync when it does change.

Can we try to reduce ghcide/exe/ to contain just Main.hs, which does the minimum to configure and run the specific incarnation it is being used for?

[ndmitchell]

I think the thing that bloated up recently is the cradle initialisation parts. That's tricky, because there is a lot of logic there, but we don't yet really know the right abstractions. We always wanted to keep the core library free of hie-bios (it makes good hygiene sense, and is also helpful for DAML), and that still feels the right line to draw, but there is increasingly more stuff left out of it.

Maybe we should wait for the multi-component stuff to land, as I imagine that is going to add more to the exe part, but also potentially show where the abstraction points can be cleanly cut to move more stuff into the library?

Or maybe once hls is in full swing, we can ditch the exe beyond basic testing, and use hls as the development host for ghcide?

[alanz]

I am happy to wait a while, for things to stabilise. The main things is to start a discussion and decide on a course for the long haul.

If that takes too long, an interim solution could be to expose a second library in ghcide with the hie-bios initialisation stuff. And we can migrate that to hls if we choose to at an appropriate time.

I know @fendor and @jneira are talking about breaking out some commonality from haskell-ide-engine too, which is shared between it and haskell-language-server. I suspect the overall transition period is going to be longer than we would like, so should probably be managed clearly.

[alanz]

I think it is time to re-visit this discussion.

Ping @cocreature @ndmitchell @fendor @jneira @mpickering and anyone else with an opinion

[ndmitchell]

I'm of the opinion that recent changes from @mpickering and @pepeiborra are still waiting to land, and we won't know the final state until they have. However, I think the direction they are going is more complexity, which needs to get shifted somewhere. I really like that idea that hie-bios doesn't intertwine with GHC API, and ghcide doesn't intertwine with hie-bios, then hls brings them both together - it seems a beautiful API separation. But it's going to require the complexity in loadSession to take be separated into a few higher-order functions if it's going to be feasible to maintain.

[pepeiborra]

Now that all our changes have landed, and the Main module in the ghcide executable stanza has grown quite sizable, perhaps it could be extracted into a ghcide-hiebios-exe library?
Given that Cabal supports packages with multiple libraries now, maybe withing the same package even.

[alanz]

I agree that it should be extracted, and s sub library in the same package makes sense.

[jneira]

That would be the optimal configuration, only want to remember that hie-bios stack based hie.yaml does not work with private libraries for now: #114

[ndmitchell]

My concern is that sublibraries aren't very well supported in Haskell. And you really have to keep it in this repo, since otherwise you can't test ghcide. But it would be nice if this code belonged to HLS, not Ghcide. It seems to be stuck between three alternatives, none of them great.

[jneira]

I would bet for creating subpackages within the repo:

• hls-plugin-api with the common modules to support plugins
• hls-plugins with all the existing plugins, they could be splitted afterwards, it will depende on the previous one.
• hlint-hls-plugin, given it needs a special configuration for ghc-lib (see Integrate HLint plugin ghcide#104). It will depend on hls-plugin-api
• ghcide-hie-bios-exe (or simply ghcide-bios?) in the ghcide repo (if maintainers agree). It will depend on ghcide and hie-bios
• hls-bios (??) with the specific hls changes over the previous one
  • given we are going to depend on implicit-hie that in turn could depend on Cabal to being able to cover more cases
  • not sure abouth this one, maybe it could be in the hls executable or fused with the previous one if everybody agree
  • it will need that ghcide-bios has the proper extension points to add the changes (with higher order functions as @ndmitchell suggested?)

[jneira]

I think this is almost done cause plugins had been reestructured in hls and the Main.hs exes for both ghcide and hls had been slimmed down. Only left make hls use ghcide master (tracked with haskell/ghcide#173)
Could we close this one @alanz?