`lsp-haskell` picks up environment of different project/repository; `envrc` related?

[peterbecich]

lsp-haskell seem to work better for me with hie-bios installed: https://hackage.haskell.org/package/hie-bios

cabal install hie-bios

Could that possibly be true, that the hie-bios binary is used by lsp-haskell? If so, can we note it here: https://emacs-lsp.github.io/lsp-mode/page/installation/

[michaelpj]

I'm pretty sure that's not the case. Why do you think it works better?

[peterbecich]

You're right; hie-bios installation has no effect.

I am wondering why lsp-haskell is using Nix here. The repo (Cabal) has no Nix configuration.

However, there are other repos with Nix configuration. When editing those repos, envrc points Emacs to that Nix configuration. The log output makes sense for one of these other repos, but the log output definitely belongs to the Cabal repo. The log output indicates that Emacs is erroneously picking up the environment of one of these other repos for editing the Cabal repo.

It could be an issue with envrc.

• lsp-haskell starts haskell-language-server-wrapper with Arguments: ["--lsp","-l","/tmp/nix-shell.4bq92D/hls.log"]
  • indicating problem precedes HLS
• the Environment Variables point to Nix
• the version of GHC is not the one on the PATH; it is the version from the Nix Flake of a different project
• the version of HLS is not the one of the PATH; it is also the version from the Nix Flake of a different project

Run entered for haskell-language-server-wrapper(haskell-language-server-wrapper) 
  Version 2.6.0.0 x86_64 ghc-9.6.4
Current directory: /home/peterbecich/haskell/libraries/cabal
Operating system: linux
Arguments: ["--lsp","-l","/tmp/nix-shell.4bq92D/hls.log"]
Cradle directory: /home/peterbecich/haskell/libraries/cabal
Cradle type: Cabal
.
.
.
2024-03-05T06:45:21.824980Z | Info | Cradle path: cabal-install/src/Distribution/Client/ProjectBuilding.hs
.
.
.
  Environment Variables
    HIE_BIOS_OUTPUT: /tmp/nix-shell.4bq92D/HIE_BIOS_OUTPUT3362904-0
    HIE_BIOS_GHC: /nix/store/xhwcdgs6gzgh5zhrpwqy8iqh3y6aam6v-ghc-9.6.4/lib/ghc-9.6.4/bin/ghc-9.6.4
    HIE_BIOS_GHC_ARGS: -B/nix/store/yirnqwbfq986hfkqla421nc88fys2lyg-ghc-9.6.4-with-packages/lib/ghc-9.6.4/lib

2024-03-05T06:45:48.016126Z | Info | Interface files cache directory: 
  /home/peterbecich/.cache/ghcide/cabal-install-3.11.0.0-inplace-a312ace59d35e084b21c5035cd9c80d1ec3eba75
2024-03-05T06:45:48.030365Z | Info | Making new HscEnv. In-place unit ids: [cabal-install-3.11.0.0-inplace]
.
.
.

I will change the title.

Thanks

[michaelpj]

Yeah, this sounds like a bad interaction with envrc. I think this has historically been a source of bugs: you get races between lsp-mode starting your server and envrc/direnv-mode changing the environment. I don't know what the overall status of that is, but it's not really something we can improve in lsp-haskell.

I actually do a silly workaround myself: I always open a non-Haskell file first when I change to a new project so direnv-mode can definitely fire before lsp-mode gets a chance :sweat_smile:

[peterbecich]

My mistake, this issue was entirely in my init file; no issue with envrc.

It was solved by fixing my exec-path-from-shell config.

Moved

(when (memq window-system '(mac ns x))
  (exec-path-from-shell-initialize))

above lsp-mode. This ensures the GHCup tools are prioritized over the Nix Flake tools. I still don't understand how it found the Nix Flake environment of a different project/directory, though.

Thanks @michaelpj