Active `cabal` version not honored, breaking HLS 2.11

[andreasabel]

First, thanks to the developers for this great tool!

Issue:
HLS 2.11 does not work with cabal-3.16, so I broke VSCode when installing cabal-3.16.
Once I figured out that this is the problem, I made cabal-3.14 my default version of cabal again (using ghcup set).
However, VSCode does not seem to honor the choice of the user, it still used cabal-3.16 which does not work.
I had to actually remove cabal-3.16 from my set of ghcup-installed cabal versions for VSCode to pick up this change.

VSCode should not simply pick up the latest versions of Haskell tools from the user's system, but follow the user's choices.

I would also be good if VSCode had some knowledge of which tools work together and which not, so it does not pick combinations that fail when guessing the configuration.

Glossary:

• VSCode = vscode-haskell

[fendor]

Thank you for raising this issue, I thought vscode-haskell uses the recommended version by default, but it actually uses the latest installed version.

@hasufell What do you think about changing this to either use the set version or the recommended one?

I would also be good if VSCode had some knowledge of which tools work together and which not, so it does not pick combinations that fail when guessing the configuration.

This was an (somewhat?) unintentional breakage, we thought we'd have enough time to do a release for HLS.
vscode-haskell does have some understanding of configurations that wont work (e.g., using an HLS version that is incompatible with the used GHC version), but the build tools should morally always work.
Not sure, whether it is worth it to add another dimension of compatibility to vscode-haskell and ghcup.

[fendor]

You can overwrite the global version of cabal by setting the option

{
  "haskell.toolchain": {
    "cabal": "3.14.2.0"
  }
}

or set it to null to use whatever is on your PATH.

[andreasabel]

{
    "haskell.toolchain": {
        "cabal": null,
    }
}

This is indeed a workaround, thanks!
A bit surprisingly, setting a value to null is not the same as not setting it...

I am usually hesitant to make settings because I forget about them and then they live on for years until they no longer solve a problem but do harm instead...
E.g. fixing to 3.14.2.0 would be in that category. I can see myself in two years confronted with an error that cabal-3.14.2.0 cannot be found and I have no clue what the cause of this error is...

[fendor]

A bit surprisingly, setting a value to null is not the same as not setting it...

Because it is intended as an overwrite, not full specification. You do the same thing for hls, stack and ghc.

[hasufell]

This was our delightful design. It's a very good design Andreas.

[hasufell]

hasufell What do you think about changing this to either use the set version or the recommended one?

Yes

[andreasabel]

In case some wanderer comes by here:

{
"haskell.toolchain": {
"cabal": null,
}
}

I have to do this in every project as this is a local setting.
And then > Developer: Reload Window as restarting the Haskell Language Server isn't sufficient to pick this up.

[fendor]

You can also set it globally in your settings.json, for example in

vim "/home/hugin/.config/Code - OSS/User/settings.json"

I can set

"haskell.toolchain": {
  "cabal": null
}

and I do, to be able to dogfood cabal head.

[andreasabel]

Ok, I can get to this configuration file via

Select the Preferences: Open User Settings (JSON) command in the Command Palette

[roninbar]

According to the principle of least surprise I think it should use the set version. That's what I expected it to do, anyway, before I knew better.