HIE crashes if there is no "ghc" on the path with explicit stack config

[alanz]

Use something like showMessage to report that GHC is not available, and suggest installing it, when starting hie.

This would help in cases such as haskell/vscode-haskell#181

[fendor]

This is related to mpickering#60 and it should not happen at all. We want to support stack-only projects with no ghc on the path.

[alanz]

@fendor I agree, but perhaps we should improve our error-reporting anyway, for those cases where this sort of thing does happen.

It seems to me that the majority of errors reported from vscode relate to readCreateProcess, and it only ever appears in the log.

So turning a readCreateProcess failure into a showMessage of what the command is that failed would help users understand the problem.

[fendor]

Absolutely. However, I dont know where this error is coming from, it should not be hie-bios.
And a lot of the failing process calls are from some internal library over which we do not have that much control, afaik.

[fendor]

Found the problem and it is not pretty:
https://github.com/haskell/haskell-ide-engine/blob/master/hie-plugin-api/Haskell/Ide/Engine/PluginsIdeMonads.hs#L348
The function BIOS.withGhc needs the system lib dir, which it retrieves with: ghc --print-libdir in https://github.com/mpickering/hie-bios/blob/master/src/HIE/Bios/Environment.hs#L54.
possible work arounds:

1. In hie-bios, dont get the system-libdir but rather ask for the path, like in ghcide: https://github.com/digital-asset/ghcide/blob/master/exe/Main.hs#L168
   • We could determine the libdir based on the cradle in haskell-ide-engine.
2. In hie-bios, use ghc-paths, like ghcide: https://github.com/digital-asset/ghcide/blob/master/exe/Main.hs#L53
   • This approach makes me uneasy. Would that entail that hie is not relocatable? E.g. copying the executable to another similar system will not work.
3. Avoid any calls to it in haskell-ide-engine.
   • Not sure if possible or desirable. (EDIT: probably impossible)

cc @mpickering

[fendor]

Personally, I would prefer (1) but I am not sure that the architecture permits it, since we are starting the server before searching for the cradle. We could probably patch it, though.

[jneira]

It seems to me that it would be good to have a dedicated part in the server startup to validate all runtime dependencies, including all executables and data files and report the result of them, as an alert error or as debug message if the validation passes.
It would suppose duplicate checks done for low level components but i think it will help us to make the reporting and to have explicitly in one place the runtime dependencies.

In this case, i think hie-bios should trigger lazily the searching of the cradle to get the ghc lib path and no assume it exist before that- (Not sure it it makes sense 😄)

[fendor]

It makes sense, but the problem is, that the ghc-lib path is needed when the ghc thread is started, which happens when the server starts.

[drewboardman]

What's the consensus on this? Should stack projects have an equivalent version of GHC installed globally?

[fendor]

That is the work around, the pr #1496 fixes the issue.