Nix Haskell Development (2020)

[cdepillabout]

Let me try to answer some of your questions. I’ll try to give you objective answers (but my answers will definitely be colored by my own experience).

@NixZeus_2

haskell.nix has a couple annoying points, but it seems like it will be the way forward for doing Haskell development using nix.

Wasn’t this a controversial opinion then?

Sort of. Especially if you consider that this opinion was coming from one of the Haskell maintainers in Nixpkgs.

To give a little historical context, at the time I originally wrote this, the Haskell package set in Nixpkgs wasn’t as big as it is now, and non-main compilers weren’t as well supported. So it made more sense to use haskell.nix if you wanted to use any compiler other than the main GHC in Nixpkgs. In my experience, a lot of people who were using Haskell professionally weren’t using the main GHC in Nixpkgs, but they were either stuck on an older compiler, or using the absolute latest compiler.

@NixZeus_2

• What about now? Has anything changed since?
• As far as I can see, there are still two competing approaches to Nix and Haskell: nixpkgs.haskellPackages vs. haskell.nix. Both exist and haskellPackages isn’t even close to being abandoned or dead.

Since the above was written there have been a bunch of improvements in Nixpkgs:

• Platforms other than x86_64-linux are much better supported.
• There are many more Haskell packages available and compiling correctly.
• Static-linking with musl works really well now.
• The non-main GHCs generally have more packages that compile with them. For instance, HLS and its transitive dependency tree will generally compile on all GHCs it supports in Nixpkgs.
• People have seemed to get pretty comfortable with functions like haskellPackages.callCabal2nix, haskellPackage.callHackage, haskellPackages.developPackage, and haskellPackages.shellFor. You’re starting to really see a lot of use of these, which makes things pretty easy.

In my experience, for a year or two after haskell.nix came out, there were a wave of people that jumped ship from Nixpkgs to haskell.nix. haskell.nix has a bunch of nice things going for it, but it also has a few downsides. In the last two years or so, there have been a non-trivial number of people that have moved back to Nixpkgs.

My guess is that if you look at all serious Haskell projects building with Nix, about half use haskell.nix, and half use Nixpkgs. Or maybe slightly more use haskell.nix.

There are two other recent solutions that may be of interest as well. Both use the Nixpkgs Haskell infrastructure under-the-hood:

• GitHub - cdepillabout/stacklock2nix: Easily build a Haskell project from a stack.yaml.lock file with Nix
• https://horizon-haskell.net/

@NixZeus_2

This is very confusing to a newcomer in 2023 who has no idea where to begin

Yeah, sorry about that

My personal recommendation is here:

Super-Simple Haskell Development with Nix

the simplest, most beginner-friendly approach to developing Haskell under Nix I think what you have here probably is the easiest approach to getting started with Nix + Haskell. For other people reading this, there are a couple other approaches to developing Haskell under Nix that you may want to consider: Use Nix to get GHC, cabal, and system deps. Then use cabal to download and build all Haskell dependencies: $ nix-shell -p haskell.compiler.ghc8104 -p cabal-instal -p zlib # zlib here i…

My recommendations haven’t changed since I wrote this, except I’d say that if you have a Stack-based project and Nixpkgs doesn’t work for you, you might want to check out stacklock2nix before diving into haskell.nix.