Nix Haskell Development (2020)

[mhwombat]

Did this ever get published (e.g., on the Nix Wiki), or is this the most up-to-date version of this excellent tutorial?

[Skyfold]

This has not been published to the Nix Wiki and I think I should update it for 2021. Its not that anything above wouldn’t work, but that there are easier and more concise ways of doing Haskell development in Nix in practice. I want to both provide a shorted version for those wanting to get started quickly, but also leave the more verbose version.

In short, one of my new years resolutions is to revisit this and add what I have learned over the past year. If this is not done by the end of the month, feel free to ping me.

[Poscat]

The current tooling works well if all of your dependencies can be compiled with the versions of packages specified on stackage. But if some of them don’t (for example if the versions are too new), it can go horribly wrong. You’ll need to manually pick specific versions of packages, and override them in the package set, similar to what you’d usually do in stack.yaml. This process is tedious, error-prone, and needs to be done every time nixpkgs updates. This is also what a dependency solver is for. I think we definitely need something that can take advantage of cabal’s solver to help us generate a build plan. Currently only haskell.nix can do this and I think nixpkgs definitely need this as well.

This issue has been addressed in greater detail in my preview post: A summary of the problems I met while using the current nixpkgs Haskell infrastructure (And my thoughts on how to solve them).

[daniil]

Thanks, the trick with overriding mkDerivation helped to pass a custom environment variable into project build with callCabal2nix inside overlay, but this solution causes nix to rebuild all dependencies (hours…).

So an alternative is appreciated.

As for me I think callCabal2nix is very limited in customization.
I don’t understand why passing environment variable is not possible.

.overrideAttrs is not working inside overlay.

I need a way to pass git commit hash. Project is fetched from git as an archive and git meta information is erased, but gitlab CI has CI_COMMIT_SHA env variable, but nix cleans env before launching GHC.

[cdepillabout]

@daniil If you throw together an example of what you’re trying to do in a repo on GitHub (and show exactly what is failing), someone may take a look and try to help you out.

[br4ch1st0chr0n3]

Hi @Skyfold! Wanna write another post for 2022 in 2023?

[NixZeus_2]

@cdepillabout

Most non-trivial projects are now using haskell.nix .

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

• This was written 3 years ago.
• Wasn’t this a controversial opinion then? 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.
• As far as I can see, most tutorials today (including those showing nix flakes with Haskell) are geared towards haskellPackages. (Of course the old Gonzales tutorial, which brought lots of people into the fold, was about haskellPackages but that’s outdated now)
• This is very confusing to a newcomer in 2023 who has no idea where to begin.

[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.

[srid]

@cdepillabout

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

And third:

• https://haskell.flake.page/
• `haskell-flake` 0.2.0 released

[nixinator]

having battled with haskell.nix, and see it turned into an absolute monster, which uses a ton of IFD (bad news for all kinds of reasons).

if you not invested or tied to any particular nix haskell build tool…

then take a look https://horizon-haskell.net/

it’s new, but it’s already proving it’s faster, reliable, stable and flexible…

[prescientmoon]

It’s not immediately clear from their website. Does the horizon thing allow building things like existing stack applications?

[nixinator]

DM me, with your details, and I’ll show you a demo.

Do you have a particular stack built app in mind? link me