Feature request: Add setting to specify `stack`/`cabal`/`ghc` path

[zbs]

I am encountering the same issue as #312, and launching code . from the command line does not cause the code server to inherit my PATH, which contains the $HOME/.local/bin directory that contains the stack binary. My hunch is that VS Code prevents the overriding of certain environment variables (such as PATH). Given that this is the case, it would be preferable if the extension allowed users to specify the location of their stack executable.

I view it as akin to the Python extension, where a user selects the location of the interpreter. They might have multiple interpreters installed, and the extension will respect whichever one is picked.

[jacobprudhomme]

Could I work on this?

[jneira]

@jacobprudhomme sure! however i cant reproduce the @zbs problem with PATH, in my windows system if i change the PATH to point to a different ghc than the default one and open code ., the ghc code uses the set one and no the default one.

There is even a trick using ghcup to set the desired ghc before opening vscode and it works for sure (in the general case):
https://www.haskell.org/ghcup/guide/#with_ghc-wrapper-eg-for-hls

with_ghc() {
  local np=$(ghcup --offline whereis -d ghc $1 || { ghcup --cache install ghc $1 && ghcup whereis -d ghc $1 ;})
  if [ -e "${np}" ] ; then
    shift
    PATH="$np:$PATH" "$@"
  else
    >&2 echo "Cannot find or install GHC version $1"
    return 1
  fi
}

There are other considerations:

• we would add three more options to an already overloaded set of
• they cant have resource scope and be able to change per workspace basis due to security reasons: see Allow using different versions of HLS for different workspaces with serverExecutablePath at machine scope #387 (comment). So you should use the same ghc/cabal/stack for all workspaces.
• we would think in the interacions between the three tools: what ghc should use cabal/tack? it will use the PATH one and no the set in the option. stack will use its internal ghc. It could produce some surprise in users, specially beginners.
• this would suppose changes not only in the extension but in the server (which in turn uses hie-bios lib to find the suitable ghc/cabal/stack).

However i really appreciate your offer, what did you choose this concrete feature? would it improve your workflow?

[jacobprudhomme]

@jneira sorry for the late response!

It seems I had misread the original issue, I have not actually experienced the same issue as @zbs (though I had a similar issue long ago). Given what you've said above, it seems it doesn't really make sense to add these configuration options 🤔

I chose this issue mainly because I thought it might be an easier entrypoint into the codebase for me to learn. It doesn't, however, really affect my own personal workflow.

[jneira]

@jacobprudhomme what about tackle anoher issue? I think #214 could be useful in different ways and i think it will not be too difficult

[jacobprudhomme]

Thank you! I'll check it out.

[jneira]

@jacobprudhomme hi, thanks to your work the new released version includes the possibility of setting the env.

I've tried to put

{ "haskell.serverEnvironment":
  { "PATH": "D:\\ghcup\\bin;D:\\ghcup\\ghc\\9.0.1\\bin" }
}

(not having ghc in D:\ghcup\bin) makes the server starts with:

Tool versions found on the $PATH
cabal:		3.6.2.0
stack:		2.7.3.1
ghc:		9.0.1

So i think it can be used to workaround the issues about the environment inside vscode.
@zbs feel free to reopen if that does not work for you