| 10 Dec 2025 |
 maralorn | And I don’t know what the specific reason is. | 11:25:40 |
| maralorn | It is probably noted in a comment in a file called broken.yaml in nixpkgs. | 11:26:07 |
| maralorn | But anyway you can remove the broken flag and see what happens. | 11:26:36 |
| maralorn | ... sbv = pkgs.haskell.lib.compose.unmarkBroken pkgs.… | 11:27:14 |
| maralorn | If you are really lucky it just builds. | 11:27:27 |
| maralorn | If you are medium lucky it builds after you apply pkgs.haskell.lib.compose.doJailbreak or pkgs.haskell.lib.compose.dontCheck to the package. | 11:28:12 |
| maralorn | If you are not lucky none of that helps and then we get to the reason why toonn recommendation might not be that bad after all. 😄 | 11:29:03 |
| maralorn | I mean every package is fixable but the effort can get larger.^^ | 11:29:34 |
 toonn | My personal preference for Haskell.nix is because it sticks to Cabal's dependency model, which is constraint resolution. The Nixpkgs Haskell infra is for when you want to package something for Nixpkgs or when you really don't want to every build your dependencies in exchange for dealing with all the version incompatibilities that implies. IMO, reasonable people can have differing opinions. | 11:44:46 |
| maralorn | Yeah, its very usecase dependent. For me staying nixpkgs compatible has a very high value. At least I had to learn the nixpkgs intricacies anyway. | 11:49:17 |
| maralorn | The dependency resolution argument for haskell.nix is very strong. | 11:49:58 |
| maralorn | I am very torn on whether in iqubics position learning haskell.nix right now would have better pay off then further learning how to fix the nixpkgs stuff. 😕 | 11:51:25 |
| toonn | Probably not something you want to do in the middle of AoC, yes. Though I wouldn't want to fight with Haskell infra either at such a time. | 11:54:02 |
| maralorn | Yeah, this should really just be working(tm). | 11:55:58 |
 iopq | if I can't compile my package on the newest nixpkgs, how do I distribute from my machine that I'm not upgrading to other computers | 13:49:05 |
| maralorn | iopq: It is not obvious to me that the sbv problem is better on an older nixpkgs. In general there are multiple solutions to pin your inputs. aka, the hash of nixpkgs. The lowest barrier would be a fetchtarball + hash based solutions others being flakes, npins or niv. | 14:01:15 |
| iopq | how do I do that | 14:04:18 |
| maralorn | https://nix.dev/reference/pinning-nixpkgs.html | 14:20:02 |
 iqubic (she/her) | Is it possible for me to just mark this as unbroken and also skip the tests too? | 16:20:17 |
| iopq | I use stack build, how do I pin a nixpkgs version while doing that | 16:21:47 |
| maralorn | Yes, just apply both functions in sequence. | 16:31:12 |
| iqubic (she/her) | Got it. | 16:31:24 |
| iqubic (she/her) | Lets see if this works. | 16:31:29 |
| maralorn | Oh, you mean you are using the stack nix integration? | 16:31:47 |
| maralorn | I think stack tries to load the environment from a shell.nix in the same dir? | 16:32:08 |
| maralorn | So if you pin nixpkgs in that shell.nix it might work? But better double check this via looking into the stack documentation. | 16:32:34 |
| iqubic (she/her) | If it doesn't I have one more thing to try. I know that my main NixOS config is building the latest version of XMonad from the Hackage, and I can just modify that to build sbv | 16:32:40 |
| iqubic (she/her) | * If it doesn't I have one more thing to try. I know that my main NixOS config is building the latest version of XMonad from the Hackage, and I can just modify that to build the actual latest sbv | 16:32:57 |
| iopq | there is no shell.nix in that folder though | 16:33:01 |
| maralorn | Then create one? But it might just not work because I am not a stack user and haven’t memorized the documentation. | 16:34:16 |
