cabal2nix in release20.03 is built using GHC881 which is not in cache

[Shimuuar]

Describe the bug
Attempt to install cabal2nix on stable channel (release-20.03) results in huge build which include such monster as GHC.

To Reproduce
Just type: $ nix-shell -p cabal2nix --dry-run you'll be greeted with long list of packages.

Expected behavior
I would expect that it should be either downloaded from binary cache or at very least will use GHC from binary cache. Digging through commit history show that cabal2nix started using GHC881 since cfb580f. Now it should probably use either GHC883 explicitly or just one from haskellPackages

Notify maintainers
@peti

Metadata

 - system: `"x86_64-linux"`
 - host os: `Linux 5.4.35, NixOS, 20.03.1754.b0e3df2f843 (Markhor)`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.3.4`
 - channels(root): `"home-manager-20.03, nixos-20.03.1754.b0e3df2f843"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

[endgame]

Looks like it's failing because bootstrapping ghc 8.8.1 segfaults? https://hydra.nixos.org/build/118296850/nixlog/1/tail

I can get ghc 8.8.2 and 8.8.3 from cache just fine; is it worth supporting 8.8.1 at this point?

Note also that haskellPackages.cabal2nix is a cache hit because it looks like haskellPackages is still using ghc 8.6.5

[cdepillabout]

I believe the reason cabal2nix comes from 8.8.1 (and not 8.6.5) is because it is kind of awkward to override Haskell packages in a package set when cabal2nix comes from that same package set:

#83098 (comment)

Looks like it's failing because bootstrapping ghc 8.8.1 segfaults?

I'm not sure why this would be happening, but an easy workaround here is to just send a PR that gets cabal2nix from ghc-8.8.3 instead of ghc-8.8.1.

[endgame]

Sounds promising, but I will not have time to do this.

[peti]

Fixed in 6b2dc0e.