Let the extension manage GHC/cabal/stack?

[hasufell]

Since we already support managing HLS, this might be the next natural step. It would probably also have to be behind a config option. Currently the extension asks the user if they want it to manage HLS, we could extend it to 3 options:

1. manage HLS only
2. manage the entire haskell toolchain
3. don't manage anything

if you pick 2., the extension will set manageHLS, manageGHC, manageStack, manageCabal to true. So users who want very fine-grained behavior can dig into the config. But the popup shouldn't ask too many excessive questions.

I guess we also want equivalents for serverExecutablePath then.

Opinions @fendor ?

Relevant:

• https://gitlab.haskell.org/haskell/ghcup-hs/-/issues/329
• https://gitlab.haskell.org/haskell/ghcup-hs/-/issues/330

[pepeiborra]

Will the managed toolchain be available outside VSCode? In other words, is the extension is driving the system ghcup or a hidden one?

If the managed toolchain is only available inside VSCode, then this doesn't seem like a good idea. Users will be confused that they can use ghc and cabal within VSCode but not without. Confusion leads to frustration both for users and maintainers.

If the managed toolchain is available everywhere, then this is fine.

I guess we also want equivalents for serverExecutablePath then.

Is this so that users can set their own toolchain binaries? Is this still needed if the extension is managing a global ghcup installation that puts things in PATH?

[hasufell]

Will the managed toolchain be available outside VSCode? In other words, is the extension is driving the system ghcup or a hidden one?

That's up to the user to decide. The extension checks for a system ghcup on first start and asks the user if they want to use that.

If the managed toolchain is only available inside VSCode, then this doesn't seem like a good idea. Users will be confused that they can use ghc and cabal within VSCode but not without. Confusion leads to frustration both for users and maintainers.

If the managed toolchain is available everywhere, then this is fine.

I guess we also want equivalents for serverExecutablePath then.

Is this so that users can set their own toolchain binaries? Is this still needed if the extension is managing a global ghcup installation that puts things in PATH?

Yes, because some users use custom binaries (forks) or wrappers, see #529

[hasufell]

Done