Reconsider cabal flags manual setting in haskell-language-server.cabal to get a hackage version with ghc-9.0 support among other things

[pepeiborra]

The flags are currently set at manual: True, preventing the Cabal solver from switching them in order to find a build plan.
This has two clear disadvantages:

1. HLS doesn't cabal install in Hackage with GHC 9.x because not all the plugins are available
2. We need to keep separate cabal-ghcXXX.project files in order to build locally, which works fine in the command line but doesn't work with the IDE because there is no way to change the cabal.project file from the cradle

On the other hand, setting the flags to manual: False has the following disadvantages:

1. Cabal can reach an unexpected/incomplete build plan if users have an older index snapshot and forget to do cabal update
2. are there any others?

To me, 1 is not something we should care about, since users doing cabal install haskell-language-server are very few these days and probably know what they are doing.

[pepeiborra]

/cc @jneira since you were the main proponent of manual: True back in the day.

[jneira]

well my main concern is just about the automatic part: not only you can get a build error but it can find a plan excluding plugins you want to be available. Terrible thing imho, even for whom "know what are they doing"

[pepeiborra]

well my main concern is just about the automatic part: not only you can get a build error but it can find a plan excluding plugins you want to be available. Terrible thing imho, even for whom "know what are they doing"

If that's the case, wouldn't the right outcome be a bug report in the Cabal issue tracker, rather than preventively disabling the feature?

Anyhow, I don't think that we should be making decisions on a hunch. Do you have any evidence of this happening including metrics of how often it does?

[jneira]

If that's the case, wouldn't the right outcome be a bug report in the Cabal issue tracker, rather than preventively disabling the feature?

Dont think so cause that unwanted behaviour would be caused for opt-in in a known feature with known caveats. The legitime response will be: dont use automatic flags if you dont want cabal choose them automatically.

Anyhow, I don't think that we should be making decisions on a hunch. Do you have any evidence of this happening including metrics of how often it does?

It is something that can happen due to how works the feature and how cabal produces a build plan.

We could release hls for ghc-9 in hackage adding explicitly conditionals to hls.cabal. We cant drop cabal-ghc*.project cause we need allow-newer's and source-repository-package's. That is the main cause of needing it and no the flags.

So setting automatic flags makes implicit and out of our control the inclusion or exclusion of plugins and could drive to suprising behaviour to final users. The build plan could exclude a plugin even if it is possible to build it cause the path to that build plan is shorter! Arguably users could set the flag in the install execution and force to include it or throw an error.

And seems to me that advantages are a matter of convenience for maintainers, to dont have to make explicit changes in config files. And dont have to rememeber to remove them. It is a valuable income but not enough to make the switch imo.

[pepeiborra]

We could release hls for ghc-9 in hackage adding explicitly conditionals to hls.cabal.

We cant drop cabal-ghc*.project cause we need allow-newer's and source-repository-package's. That is the main cause of needing it and no the flags.

I don't understand this - those allow-newer and source-repository-package are fully compatible with earlier GHC versions, so we can just copy them to the default cabal.project, right?

So setting automatic flags makes implicit and out of our control the inclusion or exclusion of plugins and could drive to suprising behaviour to final users. The build plan could exclude a plugin even if it is possible to build it cause the path to that build plan is shorter! Arguably users could set the flag in the install execution and force to include it or throw an error.

Are you absolutely certain about that? I thought that Cabal would try to find a build plan for the default value of the flags first, and only toggle the flags when it cannot find a solution.

And seems to me that advantages are a matter of convenience for maintainers, to dont have to make explicit changes in config files. And dont have to rememeber to remove them. It is a valuable income but not enough to make the switch imo.

Again, we should not make decisions on personal gut feelings. The net outcome of changing the flags to automatic is that cabal install haskell-language-server becomes possible for GHC 9.0 and hopefully soon for GHC 9.2.

[michaelpj]

So the issue is really about what happens if you cabal install haskell-language-server with a version of GHC where some of the plugins aren't supported, right? And as I understand it, these are the two alternatives:

1. Flags manual: the installation fails with a dependency solver error. This can be fixed by passing --flags to disable the plugins that don't work, but it's probably not obvious that you need to do that or which ones to disable.
2. Flags automatic: the installation works, but it silently disables plugins that don't build.

The question is which of these is worse. Both will probably result in bug reports.

My gut feeling is that the UX is less painful with 1, because a) the problem is immediately obvious, b) we can list "working" cabal install haskell-language-server --flags invocations for different GHC versions in the docs. On the other hand with 2 the problem is not immediately obvious, and we'll get users who painstakingly track down why something isn't working, only to discover it was never enabled in the first place (extremely annoying).

Possible ways to make 2 palatable:

• Make it very easy to see what plugins are enabled.
• Expand the version compatibility table to make it very clear which plugins are enabled on which versions.

[jneira]

I don't understand this - those allow-newer and source-repository-package are fully compatible with earlier GHC versions, so we can just copy them to the default cabal.project, right?

It can be done but it has its own caveat as the config used for default builds will use things which are no needed but can mask build error against hackage with no config. But to have a separate cabal-ghc.project file is independent of being flags auto or manual.

I thought that Cabal would try to find a build plan for the default value of the flags first, and only toggle the flags when it cannot find a solution.

Yeah but we have as many flags as plugins and some other ones and all our dependencies can have dozens of auto flags too, in what order will check them? will be thar order the desired one?

The net outcome of changing the flags to automatic is that cabal install haskell-language-server becomes possible for GHC 9.0 and hopefully soon for GHC 9.2.

As commented above, i think we can have a buildable version of hls in hackage for ghc-9.0 without changing flags to automatic. Maybe only changing hls.cabal file. I can try to provide a pr to demonstrate it.

[pepeiborra]

Great, then let's explore the options to fix the Hackage build with either conditionals or listing explicit flag sets in the cabal description !

[michaelpj]

I wonder whether we also shouldn't modify our statement about support after this. I think it might be clearer to say that we support GHC 9/9.2 so long as ghcide works, and then list the plugins that don't work, and direct people to the corresponding issues.

[jneira]

Yeah that is the main caveat of publish a hls version with partial support for plugins. We already were doing it for prebuilt binaries (they include 9.0.1) and noting it in the release notes but adding that to official docs would be good.

[jneira]

@pepeiborra could we close this one, as we got an explicit config to release a hackage version with support for ghc.9 or do you prefer let it open as an alternative to make it simpler?