30 Nov 2020

Haskell, Nix and using packages from GitHub

The other day I bumped into what turned out to be a bug in Amazonka where sockets weren't closed in a timely fashion and thus the process ran out of file descriptors. Some more digging and an issue later I found that a fix most likely already in place (mine was possibly a duplicate of an older issue). Now I only had to verify if that was the case by using the most recent, and unreleased code on the develop branch of Amazonka.

My first thought was to attempt to instruct Cabal to build the bits of Amazonka I need by putting a few source-repository-package stanzas in my config. That quickly started to look like a bit of a rabbit hole, so I decided to use Nix instead. After finding the perfect SO post and looking up yet again how to do overrides for Haskell I ran cabal2nix for the three packages I need:

cabal2nix --no-haddock --no-check --subpath amazonka \
  git://github.com/brendanhay/amazonka.git > amazonka.nix
cabal2nix --no-haddock --no-check --subpath core \
  git://github.com/brendanhay/amazonka.git > amazonka-core.nix
cabal2nix --no-haddock --no-check --subpath amazonka-sqs \
  git://github.com/brendanhay/amazonka.git > amazonka-sqs.nix

The relevant part of the old Nix expression looked like this:

thePkg = haskellPackages.developPackage {
  root = lib.cleanSource ./.;
  name = name;

  modifier = (t.flip t.pipe)
    [hl.dontHaddock
     hl.enableStaticLibraries
     hl.justStaticExecutables
     hl.disableLibraryProfiling
     hl.disableExecutableProfiling];
};

After adding the overrides it looked like this

hp = haskellPackages.override {
  overrides = self: super: {
    amazonka-core = self.callPackage ./amazonka-core.nix {};
    amazonka = self.callPackage ./amazonka.nix {};
    amazonka-sqs = self.callPackage ./amazonka-sqs.nix {};
  };
};

thePkg = hp.developPackage {
  root = lib.cleanSource ./.;
  name = name;

  modifier = (t.flip t.pipe)
    [hl.dontHaddock
     hl.enableStaticLibraries
     hl.justStaticExecutables
     hl.disableLibraryProfiling
     hl.disableExecutableProfiling];
};

After a somewhat longer-than-usual build I could verify that I had indeed bumped into the same issue and my issue was a duplicate.