haskellPackages.niv: Try to fix build

[maralorn]

Motivation for this change

niv is broken on master right now (compare nmattia/niv#312).

I need help on this one! /cc @peti @sternenseemann @cdepillabout

I am trying to fix this by overriding the optparse-applicative version to something older.
This should be total routine and a 5 minute job, but I have now tried for at least 30 minutes, but no matter what I do my override does not have any effect. It always tries to build with optparse-applicative-0.16.1 not with 0.15.1.

What I have tried:

• Doing the override (I know it's crazy) in all-packages.nix
• Disabling the completion generation.
• Disabling the separate bin output (as configured in configuration-nix.nix).
• When I replace the self.optparse_applicative_0_15_1_0 with anything that doesn‘t evaluate I get an error. When I replace it with anything that does evaluate it has no effect.

This is either something really stupid from my side or something really tricky in mkDerivation …

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[maralorn]

Who knows maybe I screwed up building …

@GrahamcOfBorg build niv

[sternenseemann]

For me, it builds optparse-applicative 0.15, but when configuring:

Dependency optparse-applicative -any: using optparse-applicative-0.16.1.0

I can imagine this is an issue with propagation where some dependency of niv propagates the newer optparse-applicative version.

[sternenseemann]

Might be worth trying overrideScope (compilation still running on my machine…):

diff --git a/pkgs/development/haskell-modules/configuration-common.nix b/pkgs/development/haskell-modules/configuration-common.nix
index 7d71b9e77a1..70f38b3e7f9 100644
--- a/pkgs/development/haskell-modules/configuration-common.nix
+++ b/pkgs/development/haskell-modules/configuration-common.nix
@@ -946,9 +946,9 @@ self: super: {
 
   # Generate shell completion.
   cabal2nix = generateOptparseApplicativeCompletion "cabal2nix" super.cabal2nix;
-  niv = generateOptparseApplicativeCompletion "niv" (super.niv.override ({
-   # Needs override because of: https://github.com/nmattia/niv/issues/312
-   optparse-applicative = super.optparse-applicative_0_15_1_0;
+  niv = generateOptparseApplicativeCompletion "niv" (super.niv.overrideScope (self: super: {
+    # Needs override because of: https://github.com/nmattia/niv/issues/312
+    optparse-applicative = super.optparse-applicative_0_15_1_0;
   }));
   ormolu = generateOptparseApplicativeCompletion "ormolu" super.ormolu;
   stack = generateOptparseApplicativeCompletion "stack" super.stack;

[maralorn]

Yeah, that makes sense. It’s just that I have never witnessed a problem like this before. Normally we get the error about incompatible versions it does not silently choose the "wrong" one.

[sternenseemann]

Yeah, that makes sense. It’s just that I have never witnessed a problem like this before. Normally we get the error about incompatible versions it does not silently choose the "wrong" one.

Normally Haskell packages have pretty strict PVP-based upper bounds which leads to the whole mess that we can often unbreak a build by jailbreaking, but niv has no upper bound which in this case lets ./Setup configure choose 0.16 without creating an incompatibility with anything.

[maralorn]

Yeah, that makes sense. It’s just that I have never witnessed a problem like this before. Normally we get the error about incompatible versions it does not silently choose the "wrong" one.

Normally Haskell packages have pretty strict PVP-based upper bounds which leads to the whole mess that we can often unbreak a build by jailbreaking, but niv has no upper bound which in this case lets ./Setup configure choose 0.16 without creating an incompatibility with anything.

Aaaaah, that makes so much sense.

[sternenseemann]

@maralorn niv builds successfully with this: https://github.com/sternenseemann/nixpkgs//commit/0eb47060901

[maralorn]

Thank you! I had actually tried it with overrideScope, saw how many rebuilds it required and decided "this must be the wrong solution".

[sternenseemann]

You can get it from cachix (if you have it) to verify https://app.cachix.org/cache/tmp

[SuperSandro2000]

It would be great if you could wait for ofborg.

[maralorn]

@SuperSandro2000 I think waiting for ofborg makes sense in most cases. But ofBorg should enable devs and no be a burden. In this case two people had tested this very small PR. OfBorg had made checks before my final force push.

[SuperSandro2000]

In this case two people had tested this very small PR.

Please keep in mind that ofborg uses more restricted rules to eval and what locally passes does not always need to pass ofborg.