stack VS ghcup-hs

With cabal, this works pretty well. stack doesn't properly understand internal build-tool-depends, so you have to ensure that the executable is up to date when running the testsuite:

So, I browsed online for solutions and I found this. Following this reply, I ran brew install --HEAD stack. This time the installation took significantly longer (~19 minutes). Again I ran stack ghci and got the exact same error.

The source for this command is in Stack.Build.Haddock. Stack calculates the set of dependencies and runs very long haddock commands specifying which packages to process. You can see the exact commands by running stack haddock --verbose.

Probably this issue: https://github.com/commercialhaskell/stack/issues/5607

Here is link number 1 - Previous text "PRs"

If you want better integration with ghcup, start reviewing my PRs.

and need to change my stack to use a newer version of ghc that nixpkgs switched to like ghc8106. This is actually open as an issue in the stack project https://github.com/commercialhaskell/stack/issues/4539. However it's more than just a stack issue, even if stack were to fix this part of the problem is haskell-language-server that runs haskell-lsp keeps updating its supported ghc versions. Fixing stack but being unable to use my development environment doesn't do me much good.

Following the hint to https://github.com/commercialhaskell/stack/issues/4510, I found https://github.com/commercialhaskell/stack/issues/4897 and "Overriding GHC boot packages results in any other GHC boot packages depending on it being no longer available as a dependency".

There was a proposal to introduce a brokering tool to handle this communication, but the maintainer of ghcup didn't like it very much, because this adds yet another program into the mix. They would prefer it if stack would add a hooking mechanism such that users (or ghcup automatically) can change the mechanism that stack uses for installing GHC.

Improve ghcup tui for screen readers wrt github/#4, thanks to Mario Lang