Add support for install hls from hackage using ghc 9.0.1

[jneira]

• As commented in Reconsider cabal flags manual setting in haskell-language-server.cabal to get a hackage version with ghc-9.0 support among other things #2317 (comment) it is an alternative to make plugin flags automatic to get hls buildable from hackage and ghc-9.0.1
• This pr:
  • Encode explicitly what plugins are buildable for each ghc versions in haskell-language-server.cabal, the only config file seen by hackage builds
  • Add a new flag ignore-plugins-ghc-bounds to allow custom builds out of hackage force the inclusion of plugins, supposelly adding allow-newer or remote-source-packages in a cabal.project
  • Remove all-plugins and all-formatters as afaics they are almost useless with actual default values for them and individual plugin flags and being used with || in conditions
  • Remove unused plugins conditions in test-func as almost all plugins were moved to their own packages. Deprecate the remaining ones as hopefully they will be moved sooner or later
  • Change hackage github workflow to include ghc-9.0.1 and the option to only run the check step, without upload effectively packages
  • I've added checks for ghc-9.2.1 but they are an aproximation based in the actual cabal-ghc921-project which afaiu does not work

This has not been done earlier cause i thought we should "publish" a complete version of hls in hackage. Assuming that it would not take so long to be achieved as it did.

[michaelpj]

LGTM! I guess we still need the multiple cabal.projects? I guess the ghc-9 ones should switch to setting force-plugins or whatever we call it.

Slightly off-topic, but looking at the cabal.projects, could we make the ghc-9 parts into something that could be used as cabal.project.local? That would avoid the need to repeat themselves so much, then they would basically just set force-plugins and add source-repository-packages or whatever?

[michaelpj]

Also, it might be neat to put a comment on each of these linking to the issue that describes the blocker, so if keen people end up here they know what to look for!

[jneira]

ya, i also miss that in the actual cabal-ghc<version>.project so it will improve things

[jneira]

Although all of them could point to the general issues about ghc support: #297 and #2179?

[jneira]

Slightly off-topic, but looking at the cabal.projects, could we make the ghc-9 parts into something that could be used as cabal.project.local? That would avoid the need to repeat themselves so much, then they would basically just set force-plugins and add source-repository-packages or whatever?

I tried (and got it somewhat work) here: #2241
Maybe it would be matter of reopening it

[michaelpj]

I tried (and got it somewhat work) here

Hmm I see there were various reasons not to do it. Maybe Pepe's idea of trying to make a ghc9-compatible main cabal.project that also works for the others is sensible...

[jneira]

I tried (and got it somewhat work) here

Hmm I see there were various reasons not to do it. Maybe Pepe's idea of trying to make a ghc9-compatible main cabal.project that also works for the others is sensible...

It is an option but it has its own caveats: we will use for all ghc versions package versions not in hackage. And make actual bounds work with not needed allow-newer's. They can be retrocompatible or doesnt and project buildability could differ between the project and hackage without being aware until the release is about to be done.

I am for trying hard to remove all source-repository-package and allow-newer. Isolating them in specific project config files is a way to keep the main one clean from them. We had bad experiences in the past about that.

[michaelpj]

I am for trying hard to remove all source-repository-package and allow-newer. Isolating them in specific project config files is a way to keep the main one clean from them. We had bad experiences in the past about that.

Right: if the main cabal.project is clean from those, then we should be able to release to Hackage at any time, with some plugins disabled as per the cabal files. Whereas otherwise we could accidentally make that impossible again.

[jneira]

@pepeiborra thoughts about this approach to make possible the hackage release for ghc-9.0.1?

EDIT: i've seen you reacted positively to the pr itself so i guess is fine to merge, thanks!