I’m still tying to understand how to get to an initial working condition for my Haskell project.
This was initially a stack project, which did build with the stack nix integration, but then I realized that I needed to refer to the built package somehow in my NixOS configuration.nix, which I think also means that it has to be built by the nixos-rebuild task that processes the configuration.nix, which means that I can’t use --option sandbox false, as one would do if just calling nix-build directly. (At least this is my understanding of how you get a reference to a derivation in the nix-store, for use in configuration.nix, but as my current nix understanding is so poor, I’m not even sure about that).
My project is a Haskell yesod app, and unfortunately it also has a number of dependencies included in it (with stack unpack) that I’ve had to patch up to make them compatible with ghc 9.2.5 and all its contemporary dependencies (at stackage LTS 20.11). Consequently, it has ‘copies’ of packages such as readable-0.3.1, with my own local hacks. As these are entirely local, I haven’t locally bumped the version numbers, merely included the package inside my project an fixed it it. In stack.yml I was referring to these packages in the -packages stanza, and I now have the same in my cabal.package (yes, I’ve converted to cabal too in a hope this would make my nix build easier!).
Reading the NisOS Wiki “How to develop with Haskell and Nix” page, I had some hope that I could have a single default.nix with:
let
pkgs = import <nixpkgs> { };
in
pkgs.haskellPackages.developPackage {
root = ./.;
source-overrides = {
readable = ./readable-0.3.1;
snap-server = ./snap-server-1.1.2.0;
ekg-json = ./ekg-json-0.1.0.6;
ekg = ./ekg-0.4.0.15;
};
}
Sadly though, this results in:
error: infinite recursion encountered
So I’m guessing that the enumeration of things to build in the outer project finds these references and the fact that they are declared as overrides, causes this loop.
There’s perhaps some simple magic that will prevent this (I’m hoping), in such a way that a regular cabal build would still work (i.e. leaving them in the cabal.project), but also such that haskellPackages.developPackage doesn’t go into this screaming loop.
At the moment I feel like I’m playing whack-a-mole to random-walk my way to a working nix build. I’ve also seen various examples of nix-flakes, but these look even more impenetrable atm, so my goal is to absolutely get the simplest thing working (notwithstanding the complications of the stack unpack’ed local packages).