This PR reverts some of #161, putting us back at GHC 8.10.7.
Upgrading to GHC 9.2.3 revealed a litany of blockers on macOS. Let me tell you a story...
haskell-language-server (HLS) is built against and provides a binary for GHC 9.2.2, not 9.2.3. This means that GHC 9.2.3 would effectively preclude contributors not running Nix, such as those using ghcup. (Nix builds and distributes its own binaries, including now against GHC 9.2.3.)
Considering going all in on Nix, the haskell-language-server derivation in nixpkgs is marked as broken for aarch64-darwin via nixpkgs/development/compilers/llvm/7/compiler-rt/default.nix. haskell.packages.ghc923.haskell-language-server works however it takes an age to build. Nix's core value proposition for us is dev UX, so that's unacceptable. We could consider our own binary cache but I think that's overkill.
Onto GHC 9.2.2 for compatibility with M1 contributors (for HLS via ghcup), we can pin nixpkgs to the last 9.2.2 revision with nix flake update --override-input nixpkgs github:NixOS/nixpkgs/7dc61b9. However GHC 9.x as provided by the latest version of ghcup, 0.1.17.x, is also broken on macOS. A fix is merged but won't be available until 0.1.18.x.
All in all this means that there's no way to have a good experience with GHC 9.x on macOS today. At best we could insist upon getting GHC from Nix and HLS from ghcup. That's not a good experience. With GHC 8.x on the other hand anyone can at least grab what they need externally, as most contributors have done until now. Thus I've left GHC 8.10.7 tooling in the Nix shell but without HLS for maximum compatibility across the board
This PR reverts some of #161, putting us back at GHC 8.10.7.
Upgrading to GHC 9.2.3 revealed a litany of blockers on macOS. Let me tell you a story...
haskell-language-server (HLS) is built against and provides a binary for GHC 9.2.2, not 9.2.3. This means that GHC 9.2.3 would effectively preclude contributors not running Nix, such as those using ghcup. (Nix builds and distributes its own binaries, including now against GHC 9.2.3.)
Considering going all in on Nix, the
haskell-language-serverderivation in nixpkgs is marked as broken foraarch64-darwinvianixpkgs/development/compilers/llvm/7/compiler-rt/default.nix.haskell.packages.ghc923.haskell-language-serverworks however it takes an age to build. Nix's core value proposition for us is dev UX, so that's unacceptable. We could consider our own binary cache but I think that's overkill.Onto GHC 9.2.2 for compatibility with M1 contributors (for HLS via ghcup), we can pin nixpkgs to the last 9.2.2 revision with
nix flake update --override-input nixpkgs github:NixOS/nixpkgs/7dc61b9. However GHC 9.x as provided by the latest version of ghcup, 0.1.17.x, is also broken on macOS. A fix is merged but won't be available until 0.1.18.x.All in all this means that there's no way to have a good experience with GHC 9.x on macOS today. At best we could insist upon getting GHC from Nix and HLS from ghcup. That's not a good experience. With GHC 8.x on the other hand anyone can at least grab what they need externally, as most contributors have done until now. Thus I've left GHC 8.10.7 tooling in the Nix shell but without HLS for maximum compatibility across the board
As an aside, we did discover that the bizarre GHCi line editing behaviour we've observed on macOS has been reported and is fixed in GHC 9.x.