nightly cabal?

[KiaraGrouwstra]

Hi,
For HaskTorch we're currently using Haskell.nix's shellFor, currently simply grabbing the most recent releases of cabal and ghcide: tools = { cabal = "3.2.0.0"; ghcide = "0.2.0"; };.

Now, using the latest commit of haskell.nix seems to imply using the latest commit of stackage.nix, which in turn seems to determine package versions.
However, nightly versions of Stackage use base-4.14.0.0, whereas that latest Cabal versions requires a lower version.

Using a Cabal more recent than its release should address that, but currently Haskell.nix's tool currently only allows using Stackage releases, not git commits.
This begs the question: how would anyone use one of the latest haskell.nix commits without running into this issue?

[hamishmack]

The tools and tool functions use hackage-package under the hood (which in turn uses cabalPackage). Conceptually you can think of this as a bit like running...

• cabal unpack
• cabal configure
• plan-to-nix
• import the nix and make a package set
• pull out just the exe (by default the one with the same name as the package)

The second argument to tool can be a version number or an attribute set with the arguments to hackage-package (that also get forwarded on to cabalProject). This gives us a lot of control over the steps above.

Here are some examples:

shellFor {
  tools = {
    # Compile cabal with ghc 8.8.3 instead of the compiler your project is using.
    # This is very handy since `cabal-install` in hackage does not work with 8.10.1
    # (this is the one that the recent commit fixed)
    cabal = {
      version = "3.2.0.0";
      compiler-nix-name = "ghc883";
    };
    # Set flags by specifying a `cabal.project` file to use:
    threadscope = {
      version = "0.2.13";
      cabalProject = ''
        packages: .
        package gtk
          flags: +have-quartz-gtk
      '';
    };
    # Replace a package's source (but still use the plan already created):
    sometool = {
      version = "1.0.0";
      modules = [{
        packages.somepackage.src = ./somepackage;
      }];
    };
  };
  # If you don't want to even get the package for the tool itself from
  # hackage then you are better off using `nativeBuildInputs ` and
  # `project` (new generalized version of cabalProject and stackProject)
  nativeBuildInputs = [(pkgs.haskell-nix.project {
    src = ./sometoolsrc;
    # You can have `compiler-nix-name`, `modules` etc. here too.
  }).sometool.components.exes.sometool];  
}

[hamishmack]

So:

shellFor {
  tools = {
    ghcide = "0.2.0";
    cabal = {
      version = "3.2.0.0";
      compiler-nix-name = "ghc883";
    };
  };
}

or if sources.cabal points to a download of https://github.com/haskell/cabal/

shellFor {
  tools = { ghcide = "0.2.0"; };
  nativeBuildInputs = [(pkgs.haskell-nix.project {
    src = sources.cabal;
  }).cabal-install.components.exes.cabal];  
}

[KiaraGrouwstra]

Thanks!
It turns out that since the Cabal repo can be consumed by either Stack or Cabal (:exploding_head:), it'll just yield an error as-is:

both `stack.yaml` and `cabal.project` files exist set `projectFileName = "stack.yaml";` or `projectFileName = "cabal.project";`

I tried replacing project with stackProject instead, tho that seemed to give me #69, confusing me to no end as I never even asked for this old ghc822.
(That thread mentioned more GHC versions in the IOHK fork of nixpkgs, but I can't seem to find any nixpkgs that's listing both old and new GHC versions.)

I'll try to instead put cabalProject instead now to see if that does anything.

[KiaraGrouwstra]

think this bit works -- thanks. :)

[KiaraGrouwstra]

Unfortunately, this turned out more involved than

  nativeBuildInputs = [(pkgs.haskell-nix.project {
    src = sources.cabal;
  }).cabal-install.components.exes.cabal];  

Now, cabal-install.cabal clearly states that it depends on Cabal == 3.3.*, its internal library package.
However, using the above method, my build log mentions that it's in fact filling that dependency using --dependency=Cabal=Cabal-2.4.0.1, i.e. some version it already had on hand somehow that doesn't even match the requirement.
I've tried that with exactDeps set to either true or false, but it seems stubborn about overriding this version with the bad older one.
What might be up here?

[KiaraGrouwstra]

remaining issue seems a dupe of #545

[KiaraGrouwstra]

I tried adding reinstallableLibGhc as per #545:

• inside shellFor:

        nativeBuildInputs = [(pkgs.haskell-nix.cabalProject {
          src = sources.cabal;
          modules = [ { reinstallableLibGhc = true; } ];
        }).cabal-install.components.exes.cabal];  

• inside hsPkgs

This somehow seemed to fail still, as before plugging in the older Cabal version.

[KiaraGrouwstra]

okay, so my third attempt at adding reinstallableLibGhc worked.
now tho, GHC's rts instead fails to build with warnings that seem to count as errors, _FORTIFY_SOURCE requires compiling with optimization.

[infinisil]

Fyi, I've had success with an overlay like

let
  overlay = self: super: {
    haskell-nix = super.haskell-nix // {
      custom-tools = super.haskell-nix.custom-tools // {
        cabal."3.4.0.0-rc4" = args: (self.haskell-nix.cabalProject (args // {
          name = "cabal-install";
          version = "3.4.0.0-rc4";
          src = pkgs.fetchFromGitHub {
            owner = "haskell";
            repo = "cabal";
            rev = "cabal-install-3.4.0.0-rc4";
            sha256 = "049hllk1d8jid9yg70hmcsdgb0n7hm24p39vavllaahfb0qfimrk";
          };
          modules = [{
            reinstallableLibGhc = true;
          }];
        })).cabal-install.components.exes.cabal;
      };
    };
  };
  pkgs = import nixpkgs (haskell-nix.nixpkgsArgs // {
    overlays = haskell-nix.nixpkgsArgs.overlays ++ [ overlay ];
  });
in pkgs

This allowed me to use tools.cabal = "3.4.0.0-rc4" in my shellFor

[michaelpj]

Cabal 3.4 is out properly now.