Is the current default for --[no-]system-ghc the most appropriate?

[mpilgrem]

Motivation: A discussion on Matrix about the merits and drawbacks of the current default (--no-system-ghc).

--system-ghc asks Stack to try and use the GHC on the path, if it exists and is the appropriate version. (The compiler-check: configuration tailors what is 'appropriate') This may avoid Stack creating a duplicate GHC elsewhere (if it has not already done so).

History:

• yesod devel fails for stack-built and installed yesod-bin / yesod project #1125 (comment)
• Change default to not use system-ghc unless otherwise specified. #1129
• Prefer stack installed GHC even if it's the same as the system GHC #1901
• Stop using system-ghc silently…or at all. #2221
• Default to using a stack-installed, isolated GHC #2537

The current default has applied since Stack 1.3.0 (released 2016-12-12).

(The default compiler-check: match-minor matches GHC X.Y.Z, but allows patch-level differences. So, in the case of GHC release candidates, GHC 9.10.0.20240413 and GHC 9.10.0.20240426 (for example) are not distinguished by default.)

Certain GitHub-hosted runners come with GHC on the PATH (currently, not macos-latest or macos-13). However, that is only useful in practice if the GHC version in question is specified by a Stackage snapshot. Currently, GitHub provides GHC 9.10.1 but that is not specified by any snapshot.

In the case of CI scripts, Stack provides stack config set system-ghc [--global] true.

[mpilgrem]

If --system-ghc is passed/set, Stack will not use a GHCup-supplied GHC (through the mechanism of the GHCup 'hook'), even if Stack is configured to use GHCup to fetch versions of GHC: https://docs.haskellstack.org/en/stable/yaml_configuration/#ghc-installation-customisation. (Stack will, however, seek to use a GHC on the PATH, if one exists and is the 'appropriate' version.)

History:

• Support custom GHC installation hooks #5585

[simonmichael]

Some more context, from today's #haskell-stack:matrix.org chat:

sm
Also did you know that github's ubuntu-22.04 and ubuntu-24.04 images include stack/cabal/ghc/ghcup ?
TBD: is github's stack configured to (a) use their system ghc when possible and (b) install new ghcs itself or with ghcup
A: github's stack has no config (no ~/.stack dir) so will not use their ghc or ghcup by default
How bad would it be to turn on --system-ghc by default ?
...
I noticed that --no-system-ghc is the current default, I'm sure for reasons. But it means that on github's workers, stack wastefully downloads another ghc by default. I know it does some compatibility checking, so I wonder why not use the system ghc by default.
...
right now you can use stack out of the box in github workflows, which is awesome especially for non experts. But you must know/remember to add the CLI flag every time if you want to avoid a likely wasteful GHC reinstall. If the default was reversed, you wouldn't have to think about it.
(I'm just talking about --system-ghc right now, not ghcup's hook)
...
sm
I am guessing it was chosen to avoid subtle/platform-specific/hard-to-detect incompatibilities with system ghcs. We might hope those are a bit less common these days, with more mature GHC packaging and widespread use of ghcup
sm
on the flip side, preferring a slow and failure-prone network download and install, and potential waste of 1-2G of disk space, seems not ideal
Mike Pilgrem
So, it looks like --system-ghc used to be the default, but it was changed in 2015: #2221
sm
personally I feel that's worth revisiting. Perhaps the compatibility check needed to be firmed up, rather than making stack so eager to install
Mike Pilgrem
As far as I can tell, it is because there can be more than one 'GHC X.Y.Z' 'out there'. If you allow Stack to install the GHC, you know that you are getting the same GHC X.Y.Z each time. If you use --system-ghc, you don't know what GHC X.Y.Z is on the PATH.
Mike Pilgrem
The example given - ghc-mod - was, I think, super-sensitive about the precise version of GHC X.Y.Z.
...
sm
not trusting ghc-9.10.1 is in fact a 9.10.1 version of ghc.. seems a bit of a paranoid default behaviour

[hasufell]

I think changing the default will potentially cause so much breakage that even if it is theoretically a better default, it's probably not worth it.

[mpilgrem]

@hasufell, it was a while ago now, but can you recall your reasoning for the GHCup 'hook' script not running when system-ghc: true? The reasoning did not get documented at the time, and perhaps it would be good to capture it.

[simonmichael]

From chat:

sm
I have always believed:
If you specify ghc 9.2.5 and --system-ghc, stack will look for ghc 9.2.5 in PATH.
If found, it will use it, if not it will proceed to install it.
At this point it checks for ~/.stack/hooks/ghc-install.sh and runs that (ie ghcup) if found, otherwise it does the download itself.
Is this not how it works ?

Mike Pilgrem
I don't think so, Julian wrote the documentation at https://docs.haskellstack.org/en/stable/yaml_configuration/#ghc-installation-customisation and it says "The script is not run when system-ghc: true."

sm
interesting!

• The script is not run when system-ghc: true.
• When install-ghc: false, the script is still run

Both of these are highly unintuitive to me

If the doc is accurate, definitely I had a wrong mental model (or rather, I had the right, intuitive one from classic stack, and ghcup has broken it)

[hasufell]

@hasufell, it was a while ago now, but can you recall your reasoning for the GHCup 'hook' script not running when system-ghc: true? The reasoning did not get documented at the time, and perhaps it would be good to capture it.

• system-ghc is a mechanism that searches PATH for an existing compiler
• the shell hook system executes a script which outputs a ghc binary location to stdout (which may or may not be in PATH) and may do whatever else in the process, including installation (but not necessarily)

Those are very different concepts and I don't think we should conflate them.

The shell hook is a black box (somewhat misnamed as ghc-install.sh, actually). It may:

• just output the internal stack installed GHC
• invoke nix to set up a compiler
• use GHCup to find a GHC (either by installing or erroring out if there's none installed)
• just output a compiler from PATH