| 10 Dec 2025 |
 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 |
| iqubic (she/her) | maralorn: This seems to be working for me:
GNU nano 8.7 shell.nix
{ pkgs ? import <nixpkgs> {} }:
let
src = pkgs.nix-gitignore.gitignoreSource [] ./.;
unbrokenSbv = pkgs.haskell.lib.compose.unmarkBroken pkgs.haskell.packages.ghc912.sbv_12_2;
myPkg = pkgs.haskell.packages.ghc912.callCabal2nix "aoc25" src { sbv = pkgs.haskell.lib.compose.dontCheck unbro>
in
pkgs.stdenv.mkDerivation {
name = "aoc-shell";
buildInputs = [
myPkg.env.nativeBuildInputs
pkgs.cabal-install
pkgs.haskell.packages.ghc912.haskell-language-server
pkgs.z3
];
}
| 16:40:11 |
| iqubic (she/her) | * maralorn: This seems to be working for me:
{ pkgs ? import <nixpkgs> {} }:
let
src = pkgs.nix-gitignore.gitignoreSource [] ./.;
unbrokenSbv = pkgs.haskell.lib.compose.unmarkBroken pkgs.haskell.packages.ghc912.sbv_12_2;
myPkg = pkgs.haskell.packages.ghc912.callCabal2nix "aoc25" src { sbv = pkgs.haskell.lib.compose.dontCheck unbro>
in
pkgs.stdenv.mkDerivation {
name = "aoc-shell";
buildInputs = [
myPkg.env.nativeBuildInputs
pkgs.cabal-install
pkgs.haskell.packages.ghc912.haskell-language-server
pkgs.z3
];
}
| 16:40:26 |
| iqubic (she/her) | maralorn: And my solution to the Advent of Code puzzle last night was correct. | 16:54:01 |
| iqubic (she/her) | When I built with tests, about 100 out of 80,000 failed. I guess that's why it's broken. | 16:54:28 |
| iqubic (she/her) | maralorn: Thanks for your help. I'll be going now! | 17:07:38 |
 peddie | last I checked, the sbv tests failed because they are golden output tests and when nixpkgs runs them, it invokes the smt solver by its full path rather than just by executable name, so the exact output doesn't match? not sure how or whether this can be resolved. but I bet the tests are otherwise ok | 23:20:42 |
| 11 Dec 2025 |
 andromeda | cabal2nix is to me actually quite pleasant | 05:25:53 |
| andromeda | so in Setup.hs, when I need to locate the Wayland protocols, I'm thinking I have a cabal flag to use Nix. In the Setup.hs file, if this nix flag is flown, the protocols will be found in the wayland-protocols nixpkg. Otherwise, they will be found in the 'normal' place. Does that track? | 05:52:59 |
| maralorn | custom setup.hs is not very popular | 08:35:48 |
