Support custom GHC installation hooks

[hasufell]

This adds GHC installation hooks. The feature is described in the documentation. I tested it with the newly added integration test.

[hasufell]

Any movement here? I'm happy to maintain this feature/codepath.

[mpilgrem]

May I ask what sort of practical problems the availability of this feature is intended to solve? Is it primarily that some users want to use a GHC other than a Stack-supplied one and other than one that is on their PATH? (If so, what prevents those users from adding the path to the desired GHC to the head of their PATH and using --system-ghc?) In part, as a Windows user, I am wondering if there are solutions to the main practical problem(s) that do not require a Windows user to have to know about the (MSYS2-supplied) sh application.

I appreciate that a hook that is a script is all-flexible/all-powerful, but what troubles me is: could a bad actor not sneak a damaging ghc-install.hs file into the directory, and the (possibly naïve) Stack user would not know they were executing it as they used Stack? Many Stack users would never have cause to check the contents of their Stack root.

Would it not be better to specify expressly the script to use on the command line and/or in a Stack configuration file? Stack already has --setup-info-yaml to allow a user to change the location where Stack looks for GHC when it needs to install it. Perhaps --setup-GHC-install=PATH_TO_SCRIPT?

[hasufell]

May I ask what sort of practical problems the availability of this feature is intended to solve?

Its purpose is for users to be able to decide how GHC is installed. This can be your package manager, can be a nix script or can be ghcup. Stack is not flexible enough currently to cover these use cases. --system-ghc is insufficient, because that would require the user first to figure out manually which GHC version stack actually wants (as in: the resolver in use), because otherwise stack will fail the GHC compat check and refuse to run.

Currently, most stack users of haskell-vscode use --system-ghc and ghcup, because of two reasons:

1. have only one tool install GHC, not two
2. fix ABI incompatibility issues with HLS (stack currently does not integrate well with it)
   • https://github.com/haskell/vscode-haskell#ghc-abis-dont-match and
   • ABI mismatches of GHC bindists haskell/haskell-language-server#2865

This was also the last missing piece during the (failed) unified installer proposal that caused ghcup to not install stack by default, because integration with ghcup was not really possible. This would fix it.

In part, as a Windows user, I am wondering if there are solutions to the main practical problem(s) that do not require a Windows user to have to know about the (MSYS2-supplied) sh application.

MSYS2 is installed by both stack, ghcup and chocolatey. If you don't have an msys2 toolchain, you won't be able to build a lot of packages, e.g. any package that has a configure script. It can reasonably be assumed that users have it. I won't be implementing powershell solutions or other things. This would complicate the logic and make it non-uniform across platforms.

could a bad actor not sneak a damaging ghc-install.hs file into the directory, and the (possibly naïve) Stack user would not know they were executing it as they used Stack?

No. If a bad actor can place files on the users system, they can just place a malicious stack binary into PATH.

This approach is used by git itself, many linux package managers and other tools. It's a common design pattern.

Would it not be better to specify expressly the script to use on the command line and/or in a Stack configuration file?

No, because that would mean any tool (e.g. ghcup) would now have additional complication of trying to figure out if a hook is even installed. This makes the install location somewhat predictable.

It can be debated whether to allow per-project hooks, but that can be solved in a later PR. No one has requested this for now. My suggestion is to not make this unnecessarily complicated for the first round. It can always be adjusted later.

[mpilgrem]

Thanks for the explanations. In the spirit of the recent additions to Stack's CONTRIBUTING.md, I'll merge this.

On most users wanting only one tool to install GHC, that is true for me too. I also do not want duplicate copies of GHC on my system; GHC is large and my hard drive is not. So I use only the Stack-supplied GHCs. The same is true for MSYS2 (so I use only the Stack-supplied MSYS2). I have used Stack, VS Code and the Haskell extension for VS Code (or its predecessors) for a long time.

Anecdotally - and briefly, given this Discourse https://discourse.haskell.org/t/get-a-haskell-development-environment-in-three-steps/4822 which looks like it may help me - when the VS Code extension changed recently to prompt for GHCup, I looked up GHCup to see what it was. However, I could not work out how to install it without it also installing a copy of GHC and MSYS2, which seemed to me to duplicate what I knew Stack did and provided. I was also disappointed to read in its User Guide that its basic usage was not available on Windows. So, at that time, I took up the option not to use GHCup with the extension.

[hasufell]

Also note that ghcup can easily reuse the stack msys2 installation. The user can supply an alternative location during the install script now. Windows works fine.

[hasufell]

Thanks for merging this. As I indicated, I'm happy to maintain this codepath. So ping me whenever there's an issue with it.

I'll do some follow up patches to ghcup to finalize integration with stack and will ping you for review. Ghcup development happens on GHC GitLab. Do you have an account there?

https://gitlab.haskell.org/haskell/ghcup-hs

[simonmichael]

Here are the rendered docs for this feature in current stack master:
https://github.com/commercialhaskell/stack/blob/6a7bd5d/doc/yaml_configuration.md#ghc-installation-customisation-experimental