Upgrade to Cabal 3.0.

[quasicomputational]

stack build is broken and so this probably shouldn't be merged yet.

Things I'm not quite sure about:

• Should we put in some new convenience functions for depending on only the main library? There's a lot of [ types.LibraryName.main-library ].

• Should the Text in PkgconfigVersionRange be abstracted into a PkgconfigVersion, like how Version is?

• Naming bikeshedding welcome.

[quasicomputational]

Well, that's an interesting error in CI:

Documentation created: dist/doc/html/Cabal/index.html,
dist/doc/html/Cabal/Cabal.txt
installing
Installing library in /nix/store/qinkj8nlpl8v2qcca7102gq2vc5yq1j2-Cabal-3.0.0.0/lib/ghc-8.2.2/Cabal-3.0.0.0
mv: target 'Cabal-3.0.0.0-AnMVl2OC2rpCXB4gHSOdtG.conf' is not a directory
builder for '/nix/store/vy61359zhwfldw9a3spvxhnsv3ymzj30-Cabal-3.0.0.0.drv' failed with exit code 1

[quasicomputational]

My best guess at what's going on: the generic builder is using Cabal 3.0.0.0 to build the setup component, and something in how that operates has changed that's confusing the generic builder.

Looking at the generic builder's code, which features a 'scary sed expression', it's not entirely surprising that it's been broken and will need porting.

@Gabriel439 - you know the most about Nix out of the lot of us, I think. Is that plausible? And, if you figure that's the cause, is there a way to get the Cabal package to use version 2.4.1.0 (or whatever version is handy) to build setup:Cabal while having 3.0.0.0 for dhall-to-cabal?

[Gabriella439]

@quasicomputational: Usually for this sort of thing it's easiest to upgrade to a newer version of Nixpkgs (analogous to upgrading to a newer stack resolver) assuming that the default than to try to selectively use a newerCabal`

This is the part that is responsible for selecting the revision of Nixpkgs:

https://github.com/dhall-lang/dhall-to-cabal/blob/355ef9d0fad5cab70c3a02240671414a6e652886/release.nix#L4-L10

You can simplify it a little bit by using the updated instructions here:

https://nixos.wiki/wiki/How_to_fetch_Nixpkgs_with_an_empty_NIX_PATH

... so that you can use builtins.fetchgit.

The current tip of master for Nixpkgs (https://github.com/NixOS/nixpkgs/commit/6576162fe9e6ddaf1df95429b8462e84a2ef1c06) has ghc 8.8 available with Cabal 3.0:

https://github.com/NixOS/nixpkgs/blob/6576162fe9e6ddaf1df95429b8462e84a2ef1c06/pkgs/development/haskell-modules/configuration-ghc-8.8.x.nix#L57-L67

When upgrading to a newer revision of Nixpkgs you may need to unpin or update the pinned *.nix packages in the root of this repository (analogous to having to rediscover the correct extra-deps when upgrading to a newer stack resolver).

[quasicomputational]

Upgrading the pinned nixpkgs seems to do the trick - at least, now I have Cabal 3.0.0.0 sitting in my local Nix store.

The next blockage is ghc-paths: the released version doesn't work with 3.0.0.0 (simonmar/ghc-paths#18); however, it's only used in a setup component, so theoretically this is solvable if I had the flexibility to constrain them separately. I might be able to hack around this under my own steam...

[quasicomputational]

stack test should be happy now. AFAIK there are no blockers left to merge, so I'll do that in a few days unless someone speaks up.