`haskell-flake` 0.4.0 released - with easy overrides

Announcements
1

haskell-flake makes writing Nix for Haskell projects simpler.

The 0.4.0 release mainly includes an easier way to override dependency packages.

      settings = {
        ema = {  # This module can take `{self, super, ...}` args, optionally.
          check = false;     # Disable running tests
          haddock = false;   # Disable building haddock documentation
          jailbreak = true;  # Ignore cabal constraints
          patches = [ ./patches/ema-bug-fix.patch ];
          cabalFlags.with-generics = true;
        };
      };

See Overriding dependencies | Zero to Flakes

Examples,

8 Likes
2

Thanks for you work on simplifying the Haskell setup on Nix(OS). The Haskell Nix community should agree on 1 or two variants and focus feature and documentation efforts on those. Of all packaging variants i’ve seen the “haskell-flake” approach seem to be the simplest yet comprehensive and easiest to learn solution.

2 Likes
3

given the development of the past years, it might just be too early. The various competing approaches may not be an efficient use of the resources, but it was/is impossible to tell what is the best way to do Haskell on NixOS. So I am glad that people are experimenting with different solutions.

1 Like
4

If I understand correctly, with haskell-flakes the intent is to use Nix commands instead of tools like Cabal or Stack directly?

I like the fact that it builds on nixpkgs for the main toolchain, by contrast haskell.nix are shipping their own versions of GHC, to which they apply patches IOG relies on. It also pulls many different GHC versions, I’m not sure why.

I think the ideal setup would be a mix of both: use nixpkgs as a base for the compiler and devtools, but keep Cabal as the source of truth and build a package set from it for all your Haskell dependencies. This way, you’d be free to use whatever tool you like best (Cabal, Stack or Nix) without having to rely on a predetermined package set available in nixpkgs and manually override everything you need that’s not in there.

5

I like the fact that it builds on nixpkgs for the main toolchain, by contrast haskell.nix are shipping their own versions of GHC, to which they apply patches IOG relies on. It also pulls many different GHC versions, I’m not sure why.

Yea, haskell-flake is pretty much a wrapper on top of the Haskell infrastructure in nixpkgs – meaning, you use the GHC and Haskell packages provided by nixpkgs by default.

haskell-flake is just one among various such wrappers, aka. flake-parts modules: https://zero-to-flakes.com/modules

If I understand correctly, with haskell-flakes the intent is to use Nix commands instead of tools like Cabal or Stack directly?

It replaces stack only, in practice. You still use cabal (the executable) in the dev shell―along with the .cabal file which defines the dependencies and other metadata) to build.

4 Likes
6

@srid Given this uses flake parts, you can use an lsp server like nixd (maybe nil too?) to get autocompletion for options within the flake, correct?

If so I think that’s a huge increase in usability for people curious about using Nix for Haskell that have no previous Nix experience.

7

@ParetoOptimalDev That would indeed be a good thing, but I don’t have a reason to believe this is currently possible with Nix’s lack of a good type system. Perhaps a conversation can be started on nixd/nil’s repository for this – LSP support for modules from external flakes (not just nixpkgs repo).