Old GHCs in Haskell-Stack projects


#1

As far as I can tell, stack can not install GHC on its own due to how nix works.
It needs to rely on nix to provide a GHC version fitting to the snapshot version.
However, currently it might very well happen that some GHC that you require is not in the current stable channel. I am thinking about old GHC versions, such as 8.0.1 and 8.2.1. But also newer builds do not all exist, such as 8.4.2. Since there are still lts versions where the GHC version is old, and there are projects that try to support old versions of GHC, it is currently not possible to test nor even build these projects without rewriting a substantial amount of code.

In my opinion, this is a problem, operating systems should not dictate the usage of build systems.

I have talked about this in the IRC, and Pinning Nixpkgs was named as a solution to download old versions of GHC.
This requires duplicate work for every developer on NixOS who tries to contribute to projects that support old GHC versions, since everyone needs to pin nixpkgs on their own, or have to explicitly add support for nix in their Haskell project. In general, I do not feel like we can demand that for every project.

I am curious whether there is a way to solve this problem, e.g. provide a set of all GHCs, or at least for every Stack snapshot, such that every snapshot in stack can always be built on NixOS. I am focusing on stack here, since the whole purpose of stack is to provide a unified build experience for all major platforms, which nix is currently breaking.


#2

It would be quite easy to set up a NUR repo which provided attributes for all GHC versions by downloading the binaries and patching them appropriately.

Perhaps this is what you want to set up?


#3

To be honest, I had no idea that NUR exists.
However, how could the problem be solved then? Can I tell stack to include a certain path to find the appropriate GHC?


#4

Yea. You could make a nixpkgs overlay that replaces haskell.compiler with something from NUR with all the GHC versions.


#5

You don’t have to pin the entire system onto a certain version of nixpkgs, you can just extract the packages you need from that certain nixpkgs version while keeping your own system, oldNixpkgs.ghc. Though if I were using nix-shell I would probably just use an overlay that uses the version I needed.


#6

Adding a custom overlay seems feasible, it would also help others with the same problem.

Is NUR necessary for the overlay? Would it be possible to pin a bunch of old nixpkgs for the compilers and then override the haskell.compiler namespace?

As far as I can tell, using NUR would remove the Binary Caches? That is probably infeasible, building multiple GHC’s from source takes a very long time.