# Still wrestling with the retrofitting nix to Haskell project

**URL:** https://discourse.nixos.org/t/still-wrestling-with-the-retrofitting-nix-to-haskell-project/26012
**Category:** Help
**Created:** [March 3, 2023, 11:18pm UTC](https://discourse.nixos.org/t/still-wrestling-with-the-retrofitting-nix-to-haskell-project/26012 "2023-03-03T23:18:25Z")
**Posts on this page:** 1
**Showing post:** 12

<div class="post-metadata">

### Author: ![cdepillabout](https://discourse.nixos.org/user_avatar/discourse.nixos.org/cdepillabout/32/410_2.png) [@cdepillabout](https://discourse.nixos.org/u/cdepillabout)
#### Post date: [March 7, 2023, 11:17pm UTC](https://discourse.nixos.org/t/still-wrestling-with-the-retrofitting-nix-to-haskell-project/26012/12 "2023-03-07T23:17:21Z")

</div>

> [@chreekat](#):
>
> How does it make it easier? Why not just replace the package set entirely?

I talked about this a little bit here:

> [@Nix Haskell Development (2020)](https://discourse.nixos.org/t/nix-haskell-development-2020/6170/2):
>
> Nice post! The wiki would really benefit from this information. There are only a few things I would add here: Whenever pinning nixpkgs, I’d recommend adding a comment with the date you used to pin nixpkgs. It is sometimes non-trivial to figure out the date of the channel given just a commit hash, so it is often convenient to know what date a given channel commit corresponds to. In general, you don’t need to do something like the following: (hself: hsuper: { ghc = hsuper.ghc // …

Basically, there are a set of Haskell tools that _must_ be built with with the same version of GHC you’re using. A few that come to mind are HLS, weeder, and fourmolu/ormolu (maybe?).

If you override the top-level Haskell package set (like `haskell.packages.ghc925` in the above example), you have a chance of accidentally changing dependencies of these developer tools, which can cause them to no longer compile.

Here’s a simple example. Imagine you have a local package that needs to be built with ghc-9.2.5, but uses aeson-1.5.6.0:

```nix
final: prev: {
  haskell = prev.haskell // {
    packages = prev.haskell.packages // {
      ghc925 = prev.haskell.packages.ghc925.override {
        overrides = haskFinal: haskPrev: rec {
          my-cool-pkg = haskFinal.callCabal2nix "my-cool-pkg" ./. { };
          aeson = haskFinal.callHackage "aeson" "1.5.6.0" { };
        };
      };
    };
  };
}

```

With this overlay, while you’ll be able to build `haskell.packages.ghc925.my-cool-pkg`, you likely wouldn’t be able to build `haskell.packages.ghc925.haskell-language-server`, since `haskell-language-server` requires aeson-2.0. Although, most users will want to use `haskell.packages.ghc925.haskell-language-server` in their development environment.

(This is just an example. In practice, aeson-1.5 might not compile with ghc-9.2.5, or haskell-language-server might be able to compile with older versions of aeson.)

Alternatively, if you create a separate package set, you can override whatever you want.

For example:

```nix
final: prev: {
  my-haskell-pkg-set = prev.haskell.packages.ghc925.override {
    overrides = haskFinal: haskPrev: rec {
      my-cool-pkg = haskFinal.callCabal2nix "my-cool-pkg" ./. { };
      aeson = haskFinal.callHackage "aeson" "1.5.6.0" { };
    };
  };
}

```

With just this overlay, you’ll be able to build `my-haskell-pkg-set.my-cool-pkg`, as well as `haskell.packages.ghc925.haskell-language-server`.

The takeaway here is that when working with Nixpkgs, it is very easy to create your own packages and package sets. It often helps to do so, so that you don’t accidentally override something that is used in another place.

---

_[View the full topic](https://discourse.nixos.org/t/still-wrestling-with-the-retrofitting-nix-to-haskell-project/26012)._