search

commercialhaskell / stack

The Haskell Tool Stack
http://haskellstack.org
BSD 3-Clause "New" or "Revised" License
3.95k stars 842 forks source link

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

Open mpilgrem opened 1 month ago

mpilgrem commented 1 month ago

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:

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 commented 1 month ago

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:

simonmichael commented 1 month ago

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: https://github.com/commercialhaskell/stack/issues/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 commented 1 month ago

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 commented 1 month ago

@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 commented 1 month ago

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 commented 1 month ago

@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.

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: