Cabal and HLS should coordinate the cabal-version generated by cabal init

[fendor]

Describe the feature request

HLS is about to add support for .cabal files, displaying errors and warnings, offering completions, etc...

The .cabal file generated by cabal init has the latest available cabal-version.

For example:

> mkdir example
> cd example
> cabal-3.12.1.0 init -n --lib
> head -n 1 example.cabal
cabal-version:      3.12

This poses a problem for HLS, as HLS depends on ghc, we have to use the Cabal version linked against the ghc version the HLS binary supports. This means that the cabal-version produced by cabal init is by default virtually always newer than what any HLS version supports.

This leads to an ugly error message and most features not working in the hls-cabal-plugin :

My suggestion, after talking to @Kleidukos, is to coordinate the default cabal-version produced by cabal init with the support window of HLS. As the HLS-2.9.0.1 release supports GHC 9.4 - 9.10, we consequentially need the default cabal-version to be 3.6 (assuming, ghc-9.4 is linked against Cabal-3.6) for a better UX.

EDIT: incorrect assumption of mine.
HLS 2.9.0.1 ships with Cabal-3.10, so cabal-version: 3.8 would work for us.

Additional context
HLS issue: haskell/haskell-language-server#4401

The issue is softened once private dependencies allow us to depend on a newer, private Cabal version for the cabal plugin: #9743

[ulysses4ever]

A possibly relevant prior discussion:

• Use the latest cabal spec in the interactive package init #8978

[fendor]

I realised the behaviour of cabal init -n and cabal init, i.e. interactive and non-interactive are different regarding the default version of cabal-version field.

For interactive, the default version is 3.0, while in non-interactive mode, the default is the version of the cabal-the-spec version, i.e. for cabal-3.12, the default is 3.12.

In the last cabal meeting, it was suggested to synchronise the default cabal-version (cabal-the-spec) of both interactive and non-interactive cabal init mode to the latest cabal-version that is supported by the latest HLS release.

In practice, this would mean that the default cabal-version (cabal-the-spec) is updated to 3.8 and once HLS supports Cabal-syntax-3.12, then the version should be updated to the default cabal-version: 3.12 (cabal-the-spec).
For now, it was the idea that this version update is carried out by the HLS team when we do an HLS release.

As another data point, perhaps we want to also consider the recommended version of GHCup? Since the assumption is that the recommended cabal-install version is the most used one, and we likely want to have the best support in the ecosystem, so the default cabal-the-spec version shouldn't be newer than what the cabal-install version that is recommended by GHCup supports.

Both these data points (HLS support and the version recommended by GHCup) give a good upper bound of what the default cabal-version should be.

Anyone some opinions?

[ulysses4ever]

Agreed on all points except GHCup: I always recommend using latest cabal, and I think GHCup's policy for recommended is too conservative and very subjective. Also, adding more players in the mix may make the whole process more complicated for unclear benefits: unlike HLS, ghcup doesn't really suffer from "too new" versions of cabal-versions (unless I'm missing something).

[geekosaur]

I actually agree with @hasufell re default cabal version: it's actively bad if the default cabal version is known unstable, much less actively broken, on some platform(s) (in this case Windows). We let some Windows bugs sit unfixed for too long, granting that a large part of that was that we didn't have anyone capable of debugging and fixing them until @jasagredo joined the team.

[Kleidukos]

+1 @geekosaur, the "recommended" label on a cabal release is actual valuable feedback on the quality of a release as perceived by our end-users, and I wouldn't want this mechanism to be altered, as it would shelter us (the cabal team) from reality.

[ulysses4ever]

I guess the question I'm asking: what does "default cabal version" has to do with "default cabal-version". Perhaps there's one loose connection: we may decide to not update cabal-version (as generated by cabal init) further than the recommended (by ghcup) version of cabal-install. That'd be fine with me. Don't see a need to actively negotiate it with the ghcup side though.

[geekosaur]

I agree there's still some confusion here: @fendor mentioned making the default version 3.12 in the future, but AFAICT the question is the spec version and there is no 3.12 spec version (there will be a 3.14, though).

@fendor: the spec version controls what features are available in cabal files. No new features were added to cabal files in 3.12, so there is no 3.12 spec version. 3.14 will have a new spec version because the Hooks build type is being added (note, however, that it's still a tech preview, which in practice means Hackage won't accept it yet) and ghc 9.12.1's profiled dynamic way.

[fendor]

@geekosaur I think there is a cabal-version: 3.12 version, I have it in my cabal file when I use cabal-3.12 init -n, even if 3.8 == 3.12 for all practical implications. This still breaks when HLS is linked against Cabal-syntax-3.10.

And by coordinating with ghcup, I primarily mean that we should look at the cabal version ghcup recommends for deciding an upper bound to which we bump the cabal-the-spec version.

[hasufell]

cabal.config seems to support setting this:

init
  -- interactive: False
  -- cabal-version: 2.4
  -- license:
  -- tests:
  -- test-dir:
  -- language: Haskell2010
  -- application-dir: app
  -- source-dir: src

Could the VSCode haskell extension manipulate this setting? GHCup could do that in the bootstrap process, but I'm not to keen about it. GHCup isn't a proper cabal config file manager.

Purely from a cabal perspective it seems to make sense to have "latest spec" as default, to expose all available features.

[geekosaur]

You can set anything, it just doesn't mean anything special. The actual Cabal-version: for Hooks is 3.13, so people can use it from HEAD, but people will generally use 3.14 because that's the released version that will have it.

[fendor]

You cannot set anything, cabal-version: 3.10 does not work, neither does 3.7 or 3.9, or do you mean something else? Maybe 3.13 has been special cased, or this is the first time I am hearing that.

[geekosaur]

Hm. I don't recall any changes but it appears that there is indeed a CabalSpecV3_12. Sorry.