Removing configureCabalFlags completely

[ozkutuk]

Motivation

Recently, I have been trying to get haskellPackages.diagrams-builder on nixpkgs to build. I have tried the following on my local checkout of nixpkgs:

$ NIXPKGS_ALLOW_BROKEN=1 nix-build -A haskellPackages.diagrams-builder

However, this failed with the following error:

Setup: Encountered missing or private dependencies: diagrams-postscript >=1.4 && <1.5

Fair enough, since diagrams-postscript on nixpkgs was version 1.5.1.1. Then I proceeded to jailbreak the package by adding the following to configuration-common.nix, and try again:

diagrams-builder = doJailbreak super.diagrams-builder;

Oddly enough, the error didn't change at all!

After spending some time together with @dalpd, we got this figured out. diagrams-postscript was only required when the ps cabal flag of diagrams-builder was enabled, and we theorized that that was probably the reason why jailbreak didn't seem to have any effect. However, there was still a question to be answered: the ps flag is disabled by default, so why was it seemingly enabled while building from nixpkgs?

The problem

After digging some more into the issue, I have found the culprit to actually be cabal2nix! Namely the following line enables the ps flag:

cabal2nix/cabal2nix/src/Distribution/Nixpkgs/Haskell/FromCabal/Flags.hs

Line 24 in 0783500

| name == "diagrams-builder" = [enable "cairo", enable "svg", enable "ps", enable "rasterific"]

I have found this to be very strange: Aren't such overrides meant to performed in configuration-*.nix family of files within nixpkgs? Looking at rest of the configureCabalFlags function, nothing in it seemed to be something that couldn't be done within the configuration files in nixpkgs.

Proposal

Let's remove configureCabalFlags all together and merge the flags to the haskell-nixpkgs configuration files. Having multiple sources of truth is confusing, and leads to nasty problems like this. Looking at the history of the Flags.hs file, it seems to be merely maintained for the existing entries added years ago, and no new flags are getting added, suggesting the existing haskell-nixpkgs infrastructure is enough to handle such overrides.

Finally, I only have a minimal understanding of the haskell-nixpkgs' inner workings, and it may be entirely possible that configureCabalFlags has other uses than the one I mentioned. If that's the case, please let me know.

[sternenseemann]

This is a duplicate of #504 which was already discussed a bit. The problem, basically, is one of backward compatibility: Existing users of cabal2nix and callCabal2nix may (reasonably) expect these flags to be applied automatically, so it is a bit of a question how to proceed.

Additionally, it is also quite a bit of work. Since 2021 we haven't added any postprocessing except to smooth out system library detection and kept everything as is.

I'll close this issue, as it is basically a duplicate, but feel free to add your thoughts on the other issue.

I have found the culprit to actually be cabal2nix!

Well, in addition with jailbreak-cabal not touching bounds inside of conditionals, as that would break cabal's automatic flag solving. At least it is looking good now that we'll be able to use cabal-install-style --allow-newer instead which would also work for conditionals: haskell/cabal#9016