Don't create `~/.cabal` if `~/.config/cabal` exists

[geekosaur]

Your environment

Which OS do you use? Ubuntu 20.04
Which version of GHC do you use and how did you install it? 9.2.5 from ghcup
How is your project built (alternative: link to the project)? https://github.com/geekosaur/xmonad.hs/tree/skkukuk
Which LSP client (editor/plugin) do you use? VS Codium+vscode-haskell
Which version of HLS do you use and how did you install it? 1.8.0.0 from ghcup
Have you configured HLS in any way (especially: a hie.yaml file)? No

Steps to reproduce

Start HLS. (This will fail in my configuration because ghc 9.2.5 is not supported, but that's a separate ticket.)

Expected behaviour

~/.cabal is not created if ~/.config/cabal exists.

Actual behaviour

Cabal 3.9/3.10pre supports XDG compliance, which moves various cabal files to XDG compliant locations and no longer uses ~/.cabal. If it finds ~/.cabal it switches to compatibility mode. Starting HLS currently always creates ~/.cabal and I must remove it after starting HLS by any means so my package store will be found.

Cabal 3.10 is currently in pre-release testing, so this currently affects only a few people but will likely become more common as the 3.10 release date approaches.

Debug information

[fendor]

Hi!

Have you made sure this is not a cabal bug?
If I am not mistaken, the only place where we actively invoke the cabal command, is hie-bios, which doesn't touch ~/.cabal at all but uses only CLI, e.g. cabal run and cabal repl. Can you reproduce the issue with hie-bios debug <some-source-file>?

[geekosaur]

Sorry for the delay on this.

Where is hie-bios? I don't see anything other than a cache directory and a package entry for it under my $HOME. My HLS was installed via ghcup, but it's not under any of the ghcup directories either.

[fendor]

hie-bios is responsible for figuring out the project type and to find the compilation flags. Install the executable via cabal install hie-bios, and then call hie-bios debug <some-source-file>. Check whether afterwards the ~/.cabal directory has been created to further circle the issue.

[geekosaur]

~/.cabal is not created.

I'm going to run HLS under strace to see if I can narrow down what's creating it.

Edit: This is peculiar. I have not updated anything, but ~/.cabal is not being created any more. I have not updated either cabal or haskell-language-server since filing this ticket. Could installing a new hie-bios do it?

[geekosaur]

But it is still being created if I run code with haskell-language-server enabled. Perhaps it's their bug after all.

[geekosaur]

Have not tracked it to origin yet, but the smoking gun is:

execve("/home/allbery/.cache/ghcup/tmp/ghcup-cabal-3.8.1.0_hls-1.8.0.0_stack-2.9.1/cabal", ["cabal", "exec", "-v0", "--", "ghc", "--print-libdir"], 0x42017ddac8 /* 73 vars */) = 0

Something is running the wrong cabal: the cabal I have selected with ghcup is a HEAD build from a few weeks ago.

[geekosaur]

Parent process is:

execve("/home/allbery/.cache/ghcup/tmp/ghcup-cabal-3.8.1.0_hls-1.8.0.0_stack-2.9.1/haskell-language-server-wrapper", ["haskell-language-server-wrapper", "--project-ghc-version"], 0x3c64002a8480 /* 73 vars */) = 0

Appears it is your issue after all. Is there some reason it's not using the ghcup-selected cabal?

[fendor]

Looks like a vscode bug, I am going to transfer the issue.

Aha, yeah, maybe a ghcup user "bug"? Probably, ghcup doesn't care about pre-installed cabal versions, even if they are installed via ghcup, it only defaults to "latest" or something?

EDIT: you installed cabal via cabal install, I presume? In this case, you likely want to not have cabal managed by ghcup, from https://github.com/haskell/vscode-haskell#setting-a-specific-toolchain, maybe you want to try

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

in your workspace/global settings?

[geekosaur]

haskell-language-server-wrapper appears to have run the cabal corresponding to its ghcup install. I would have expected it to use one on $PATH.

I did not explicitly manage it with ghcup; it's finding it because I'm using XDG paths (~/.local/bin).

[fendor]

Yeah, it does, but vscode-haskell manipulates the PATH to make sure sane versions are installed and used.
Just tell vscode-hasell to not handle these tools by specifying the toolchain as above.

[geekosaur]

Looks like it still used the wrong cabal.