How do I include patches to haskell dependencies?

I’m trying to patch one of my app’s dependencies using overrides.

The above code doesn’t work. The patch gets applied, and jsaddle-warp gets built, but when my app is built it does not use the modified dependency. I get the unpatched behavior.

However, if I uncomment the src line (so that it’s building jsaddle-warp from a local source directory), then my app does use the modified package.

Why is this happening, and how can I override a package by adding patches?

1 Like

Probably not super relevant, but the way to repro is:

  1. cachix use miso-haskell
  2. cd usort-web
  3. nix-shell --run reload
  4. (wait a while)
  5. Navigate to localhost:8081/blahblah

In the patched behavior, you should get a 404 Not Found.

In the unpatched behavior, you should get a 403 Forbidden.

There should be some examples of adding patches to Haskell packages in nixpkgs/configuration-common.nix at 09eb860c995d4b8d875c6322fe573cc01918e357 · NixOS/nixpkgs · GitHub (grep for patch).

Let me know if these examples don’t end up working for you.

1 Like

Yeah, but here, something strange is going on regarding the haskell packages recursion. As soon as any function using overrideCabal is involved, the patched version is still compiled but not used.

I cannot reproduce the patched behavior if setting src but, I only get it if I completely bypass the jsaddle-warp from miso. This seems to be because it uses dontCheck pkg, which is

dontCheck = p: overrideCabal p (_: { doCheck = false; })

. Although, I can use successfully

let p = self.callCabal2nix "jsaddle-warp" super.jsaddle-warp.src {};
in p.overrideAttrs (_: { doCheck = false; patches = [...]; })

. As soon as I use dontCheck or addPatch it breaks down. Maybe the overrding in miso is not totally correct? Have you tried a newer miso version, @chreekat?

That’s quite interesting - thank you for the hints! I have not had a chance to look into this yet, but if/when I do I will report.

I’m afraid this just deepens my suspicion that using fixpoints as a fundamental design choice for building package sets makes things obtuse. (Of course, I’m being hypocritical - the very package I am trying to build uses them in two different places!) If anyone knows of good ways of debugging the recursion, that would be great.

At least mixing one-shot overrides and the recursion leads to surprising results…

Well, this is not really sophisticated debugging but I found simple trace markers helpful, in the nix and in the haskell code, so that you see what gets evaluated (how many times) and what executed. I would use local copies of miso and nixpkgs, so that I could add markers there.

1 Like