Updating the build process and dependencies; using Cabal and Nix

I still can’t even build Snowdrift on my NixOS 20.03 laptop, so updating the build process is my next project. Plus, we haven’t updated our Haskell dependencies since 2017, so I’m gonna update that as well.

Cabal and Nix are the tools I use on a daily basis these days, so I would like to switch Snowdrift to those tools. I should probably explain my rationale for doing that, but first — does anybody really care? ./build.sh devel will continue to work as before (that’s the whole selling point for having build.sh in the first place! :smiley: ), and I don’t think there’s too many people running stack directly these days. But let me know if I’m wrong.


I don’t really care about (or rather, I trust) your reasoning. I do care about outcomes:

  • Does this require different dependencies (eg, nix) to be installed systemwide? Specifically,
    • Does this affect the number of supported platforms?
    • Does this increase the number of 3rd party repos I need to install on my system?
  • Does this affect compile times? (Longer or shorter)
1 Like

Different dependencies systemwide?

With Nix, the dependency instructions become:

  1. Install Nix
  2. You’re done.

Nix does the rest, since it’s a package manager first and foremost.

Supported platforms?

The supported platforms for Nix are Linux and Mac, which is basically what we currently support, I believe. There is some ongoing misery regarding Macs on the latest OS (Catalina). The fix was merged two days ago and isn’t released yet. So, Catalina users beware.

Increase the number of 3rd party repos?

Yes, I’m afraid so. Good point. If we use Nix, /nix will become a non-trivial resident of your hard disk. This is somewhat offset by lessening the pressure on ~/.stack and/or ~/.cabal, since most Haskell dependencies will come from Nix.

Does this affect compile times? (Longer or shorter)

My hypothesis is that this will be a good change for compile times.

Initial load

Unlike with Stack on its own, using Nix means you get to download pre-compiled libs for all our dependencies. If your bandwidth is ok, that’s probably a lot faster than building all of them.


No appreciable difference


No appreciable difference


Is the default approach to garbage collection in Nix decently efficient? Or is there a setting we may want to tell people about if they prefer to err toward less disk space use over time vs more?

Hm - no. Nix doesn’t do garbage collection on its own. You must manually run a command or set up a scheduled job. (I run them automatically via a NixOS option that sets up such a scheduled job.)

My time available for Snowdrift has gone back to near zero. I probably won’t make much progress on this now anyway.