Conflicting definitions for flag overrides for cabal projects

[hamishmack]

#253 allows flags to be specified in stack.yaml or cabal.project and haskell.nix will use the values specified as the default. This works well for stack.yaml where we add overrides only for the flags explicitly listed in the stack.yaml file.

For cabal.project we read the plan.json file that includes the values of all the flags (not just the ones that were explicitly set).

For instance if we try to override mypackage flags with:

mkCabalProjectPkgSet {
  plan-pkgs = plan.pkgs;
  modules = [ { packages.mypackage.flags = { flag1 = true; flag2 = false; }; } ];
}

We might get an error that says:

error: The option `packages.mypackage.flags.flag1' has conflicting definitions, in `<unknown-file>' and `<unknown-file>'.

There are two quite good work arounds for this:

We can specify the flag in the cabal.project file instead with:

packages: .

package mypackage
  flags: +flag1 -flag2

Alternatively we can use stdenv.lib.mkOverride

mkCabalProjectPkgSet {
  plan-pkgs = plan.pkgs;
  modules = [ { packages.mypackage.flags = {
    flag1 = mkOverride 10 true;
    flag2 = mkOverride 10 false; }; } ];
}

A possible fix to this might be to patch the cabal to include which flags were explicitly set in cabal.project and which were not in the plan.json.

[michaelpj]

Can't we just use mkDefault on the options that we set? That's the usual idiom for setting options where you want any user setting to take precedence.

[hamishmack]

Oh, that would be nicer. Would it be surprising to anyone that when a flag is set in both cabal.project and modules that modules would quietly take precedence? I think it would be natural.

Should we change stack-to-nix to use mkDefault as well?

[michaelpj]

Yeah, I think we should do something like:

• If this option might be set by a user and their setting should just take precedence, use mkDefault.
• If this option could be set by a user but they had better know what they're doing otherwise things will behave unexpectedly, use a normal setting.

[hamishmack]

This was fixed by #258