graphical editor not detecting ghc/cabal/stack due to incomplete $PATH in the init config file

[dreamsmasher]

I'm having some issues with getting the extension to work right - currently, my Cabal installation is from ghcup, and Stack is built from Cabal (GHC 8.8.3). When loading projects in VSCode, I keep getting the error Project requires Cabal but it isn't installed. Stack projects give me the same error but with Stack, and the installation link just takes me to the ghcup page.

I've tried downloading the binary from the releases page and manually adding it to my configuration, as well as building it from source. No luck whatsoever, and using ghcide with the haskell-language-server-wrapper doesn't work either.

System: Arch Linux, i5-7600k, 16GB RAM, GHC 8.8.3

hie.yaml:

cradle:
  cabal:
    - path: "src/Main.hs"
      component: "mmvm:exe:mmvm"

    - path: "src/LibBinary.hs"
      component: "mmvm:exe:mmvm"

    - path: "src/Parse.hs"
      component: "mmvm:exe:mmvm"

    - path: "test"
      component: "mmvm:test:test"

    - path: "src"
      component: "mmvm:test:test"

settings.json:

{
    "editor.fontSize": 16,
    "editor.fontLigatures": true,
    "editor.fontFamily": "Hasklig", 
    "editor.fontWeight": "normal",
    "debug.console.fontFamily": "Terminus (TTF)",
    // "editor.suggestSelection": "first",
    // "vsintellicode.modify.editor.suggestSelection": "automaticallyOverrodeDefaultValue",
    "editor.cursorStyle": "block",
    "python.jediEnabled": false,
    "editor.suggestSelection": "first",
    "terminal.integrated.shell.linux": "/bin/zsh",
    "terminal.integrated.fontFamily": "Hack", 
    "terminal.integrated.fontSize": 14,
    "vscode-neovim.neovimPath": "/usr/bin/nvim",
    "vscode-neovim.neovimInitPath": "~/.config/nvim/init.vim",
    "terminal.integrated.fontWeight": "normal",
    "terminal.integrated.fontWeightBold": "bold",
    "python.pythonPath": "/bin/pypy3",
    "workbench.colorTheme": "Wal",
    "haskell.enable": true,
    "haskell.hlintOn": true,
    "C_Cpp.clang_format_path": "/usr/bin/clang",
    "telemetry.enableTelemetry": false,
    "telemetry.enableCrashReporter": false,
    "window.zoomLevel": 2,
    "haskell.logFile": "/home/normie/Documents/misc/hs-hls.log",
    "haskell.trace.server": "messages",
    "haskell.formattingProvider": "brittany"

}

Any help would be appreciated, I'm currently doing fine with ALE/neovim but I'd like to be able to use an IDE for larger projects. Thanks!

[lukel97]

This is a bit of a silly question, but have you made sure that cabal/stack are on the PATH from VS Code? I.e. can you open up a terminal in VS Code and type cabal repl/stack repl is it able to find it?

[dreamsmasher]

Yes, both cabal repl and stack repl work in the VSCode terminal.

[lukel97]

Hmm then perhaps that the PATH VS Code is launched with is different from whatever your shell is set as. Were you launching Code from a graphical shell? Is it able to find the binaries if you instead launch Code from your shell via code .?

[cronokirby]

This project:

https://github.com/cronokirby/reg-viz/tree/679ed7e7f25b67d1fc96ef4bba11e7c3c759ede2

Exhibits this error as well, at least on my Linux (Manjaro) machine.

cabal and ghc are available on the PATH, installed through ghcup, and available in the integrated terminal inside VSCode.
The project builds fine as well.
What's odd is that it was working fine when I started working on the project (before there were any haskell files, just a cabal file), and kept working until I reloaded VSCode, now it doesn't work regardless of if I launch VSCode in a terminal with code . or just open it as a desktop application.

[gwils]

I get this as well, also on Arch Linux. I got my GHC and cabal from ghcup.
edit: The version I get is Project requires GHC but it isn't installed

[lukel97]

@gwils @cronokirby @dreamsmasher Can you try cloning this branch of the extension and running it locally, and see what the PATH error message says? https://github.com/haskell/vscode-haskell/tree/path-debug
You should be able to open the project in vscode and just click the run button in the run sidebar, and it should open up another vs code window from which you can open a haskell project or the like

[dreamsmasher]

Sure thing, I’m out of town for a few days but I’ll update when I’m back. Thank you for the help so far.

(also code . didn’t work for me)

[gwils]

The PATH I get from the extension is:

PATH: /opt/google-cloud-sdk/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl

in bash/zsh I get

echo $PATH
/home/george/.cabal/bin:/home/george/.ghcup/bin:/home/george/.cabal/bin:/home/george/.ghcup/bin:/opt/google-cloud-sdk/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl

Note the extra entries on the front - they are added in my .bashrc and .zshrc, courteous of the ghcup installation script.

Edit: By the way, I tried code . from within my shell, and it seems to make it work correctly. I'll use that as a workaround for now!

[gwils]

I've found a better fix for this - rather than adding /home/george/.ghcup/bin and /home/george/.cabal/bin in my .bashrc and .zshrc, I add them in /etc/profile. If I do this, then VSCode/Haskell Language Server will happily pick up the necessary executables and run correctly.

I suspect this fix will work for others on Arch Linux and its derivatives such as Manjaro.

[yousefvand]

Maybe this is related to vscode-oss which is the official package on Arch. Path:

/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl

[georgefst]

I've found a better fix for this - rather than adding /home/george/.ghcup/bin and /home/george/.cabal/bin in my .bashrc and .zshrc, I add them in /etc/profile.

This is the solution. You could also use .profile rather than /etc/profile to set for just the one user. The integrated terminal reads .bashrc, but you wouldn't really expect VScode itself to do so.

I'm not sure there's anything for HLS to do here, except maybe add this info to the README? Since it is admittedly easy to hit, and potentially frustrating.

[georgefst]

Having said that, actually, there may be reasons to not want to add ghc to PATH in .profile.

Perhaps HLS should just provide the option to set the path to ghc explicitly.

[dreamsmasher]

New release of HLS stopped the error from occurring anymore. Thank you to everyone who gave advice!

[grizwako]

Hey, I am on Manjaro/Arch Linux and just ran into this issue today.
Did not have anything Haskell related installed until now.
Used only ghcup to install everything.
When it did not work on the first go, tried cabal new-install Cabal cabal-install too.

Not my first time trying to trick "haskell IDE stuff" into actually working, so I kept digging and finally ran into this issue.

Newcomers might get discouraged by this easily, especially since "cabal and IDE story is fixed now".
Adding options to set paths in Extension Settings is good and probably what should be done.
Adding info about PATH issues on some distros is OK too, or perhaps even modifying ghcup so it tosses some symlinks to some of the */bin directories.

[georgefst]

New release of HLS stopped the error from occurring anymore. Thank you to everyone who gave advice!

What changed? I'm not sure this is really resolved, as evidenced by @grizwako's issues.

Another option we have would be, rather than polluting the README, to modify messages like Project requires Cabal but it isn't installed to something like Cabal binary not found. If it is installed then perhaps add it to your path in ~/.profile.

Also, do we know if this is actually symptomatic of Arch (or possibly VScode OSS?)? What is e.g. Ubuntu doing differently?

[georgefst]

Actually, seeing as everyone here seems to have come from ghcup, perhaps the real solution is for ghcup to offer to add its paths in .profile rather than .bashrc/.zshrc.

@hasufell Is there any reason not to do this? (To précis the above, certain editors will read only .profile, and so HLS fails to find ghc and cabal on PATH.)

[georgefst]

perhaps the real solution is for ghcup to offer to add its paths in .profile rather than .bashrc/.zshrc

Come to think of it, I believe this is what rustup does anyway.

[hasufell]

Actually, seeing as everyone here seems to have come from ghcup, perhaps the real solution is for ghcup to offer to add its paths in .profile rather than .bashrc/.zshrc.

Clarification: ghcup doesn't do that (and never will). The bootstrap script does that (the thing that runs when you do the curl command).

@hasufell Is there any reason not to do this? (To précis the above, certain editors will read only .profile, and so HLS fails to find ghc and cabal on PATH.)

The bootstrap script tries to not guess too much and keep editing user files to an absolute minimum. This can always go wrong, even if you print 20 warnings to the user. They'll just press enter and then something is messed up, because we couldn't anticipate every possible configuration.

That said, .profile is only used by a couple of shells: Korn Shell, Bourne Shell (the old one, not bash), dash... anything else?
The shell detection logic would have to be extended: https://gitlab.haskell.org/haskell/ghcup-hs/-/blob/master/bootstrap-haskell#L233
That is possible.

However, I don't know exactly what VSCode is doing here anyway. We don't want to edit files "just in case".

[georgefst]

Clarification: ghcup doesn't do that (and never will). The bootstrap script does that

Apologies - that is indeed what I meant.

That said, .profile is only used by a couple of shells

Ah, I hadn't realised that bash only reads .profile if .bash_profile doesn't exist. That is admittedly a slight complication.

[georgefst]

Note that haskell/ghcide#577 is essentially the same issue as this.

[jneira]

reopen, as it would need at least some documentation (change ghcup would be an option?)

[jneira]

That said, i am not against a config option to set ghcup as it could be useful in its own, so pr's would be welcomed.

[jneira]

This affects all graphical editors as it is directly caused on how linux windows managers handle the user environment.
Windows does not have this problem, afaics.

[jneira]

This seems to be a common issue bewteen vscode and other graphical editors unsing the lsp protocol.
See this generic so question: https://stackoverflow.com/questions/43983718. There are several answer which could be useful.

[jneira]

Hi, the last version of the vscode extension just released lets you set a specific environment for the lsp server wrapper, so you can set a specific $PATH in the extension itself writing in .vscode/settings,json:

{ "haskell.serverEnvironment":
  { "PATH": "/path/to/hls:/path/to/ghc:/path/to/cabal" }
}

@georgefst would that also work as an acceptable workaround?

I think this is essentially a issue in the interacion between the editor and the linux/macos window manager and we can only provide workarounds like the mentioned one.
So i am inclined to close this one as blocked upstream if nobody disagree

[georgefst]

@georgefst would that also work as an acceptable workaround?

Yes, that's one solution. At the very least, I think HLS should prompt the user toward filling in that setting, whenever it fails to find GHC.

[georgefst]

Hi, the last version of the vscode extension just released lets you set a specific environment for the lsp server wrapper, so you can set a specific $PATH in the extension itself writing in .vscode/settings,json:

This isn't making any difference for me on a new M1 Mac. And unfortunately, neither are any of the other suggestions in this thread.

I always get "Project requires GHC but it isn't installed".

EDIT: at some point this just started working, and I can't work out what changed.

[bakuhatu]

I'm on void linux and tried adding that PATH snippet, but I also get "Project requires GHC but it isn't installed". I tried adding the path of the language server in the "Haskell: Server Executable Path" setting, and the "GHC isn't installed" warning goes away, but still doesn't work.

[sepehr500]

Having the exact same problem as @bakuhatu

[hasufell]

haskell/vscode-haskell#547 will fix this in the following way:

1. ghcup can manage all your toolchain via VSCode
2. if you let ghcup manage your toolchain, all the extension needs is the binary (if it doesn't find it, you can set haskell.ghcupExecutablePath). The extension will then make sure that HLS, cabal, ghc, etc. are also in PATH automatically.
3. alternatively you can add this to your settings: "haskell.serverEnvironment": { "PATH": "${HOME}/.ghcup/bin:${PATH}" }

[deividrvale]

It seems starting code with --force-user-env can help to set the correct PATH within vscode

That solved it for me. So does that mean vscode doesn't use the user env by default?

[ghost]

Putting this in settings.json as suggested by @hasufell worked for me:

"haskell.serverEnvironment": { "PATH": "${HOME}/.ghcup/bin:${PATH}" }

Thank you for adding this setting! I'm also on Arch Linux with Xfce and VSCodium, installed from the curl script.

[michaelpj]

Tentatively closing since it seems there's an appropriate setting for this in the extension now

[hasufell]

We could add some logic in HLS, so it searches for a ghcup binary via:

• examining some static directories (like ~/.ghcup)
• spawning a terminal ($TERM) and then analyzing PATH there (which may be different if vscode was started via GUI)

And then possibly ask the user if they want to augment their PATH via vscode settings.

[michaelpj]

I do think this is a client (extension) issue though. I think HLS itself should just expect to be launched with the correct PATH set.

[hasufell]

Yes