| 9 Dec 2025 |
 andromeda | so like MangoIV said I would be using Cabal as the 'source of truth' and Nix just as a convenience dev environment for those who have it. | 09:16:05 |
 maralorn | Ah, I see | 09:16:24 |
| andromeda | Nix's flexibility is a blessing and a curse xD | 09:16:49 |
| maralorn | My best flake is probably this one others might have cleaner ones: https://github.com/maralorn/nix-output-monitor/blob/main/flake.nix | 09:19:33 |
| maralorn | But I am not saying that everything in there is recommended for every project | 09:20:20 |
| andromeda | yo you write nom!? Awesome! I use it every day | 09:20:38 |
| maralorn | Anyway the spirit of nixpkgs is generally to reuse language specific build instructions instead of dodging them. | 09:22:33 |
| maralorn | This is imo not a failure to separate concerns | 09:22:51 |
| maralorn | nix does not know anything about Haskell or cabal | 09:23:14 |
| maralorn | But nixpkgs is a suite of libraries to build projects from all kinds of ecosystems. Using such a library to build a Haskell package seems smart to me instead of redundant. | 09:24:32 |
| andromeda | I love that despite there being a 'right' way to do Nix, it's such a powerful and general tool that you can go literal years doing it the 'wrong' way without a hitch | 09:27:29 |
| maralorn | Also your approach seems slightly dishonest because when you use ghcWithPackages you still rely on tons of packages being built with our Cabal based builder and e.g. it uses bespoke code to put a DB in your environment which cabal-install understands. So you are not really getting rid of the layer mangling you are complaining about. | 09:28:11 |
| maralorn | That being said no one is stoping you from doing it your way. 😆 | 09:29:00 |
| maralorn | I personally think that the redundancy of the usual approach is not a problem. Because all the redundant information can be auto-generated on the nix side by cabal2nix. | 09:32:14 |
| andromeda | this is where I am now, I'll shift it to a Cabal-centered approach after school. Lmk if you have any other cool tips! | 09:35:32 |
|  Morj joined the room. | 10:44:13 |
| andromeda | I lied I'm going to mess around with FFI to see if I can get RGFW working instead of GLFW :) | 18:57:59 |
| andromeda | Ok so it's not working. I've been trying to troubleshoot for a while... maybe it's the way I've linked dependent libraries? Maybe it's a type error in my FFI? A brief look-around by someone smarter than me would be greatly appreciated... one again ignore the atrocities that are the build process... https://git.mtgmonkey.net/Andromeda/hs-rgfw | 22:01:48 |
| andromeda | the problem is that a window doesn't appear and window_shouldClose is immediately false, leading me to believe a type representation error or a windowing dependency error has occuredd | 22:03:19 |
| 10 Dec 2025 |
| andromeda | once I remove the #define RGFW_WAYLAND it works for 1 frame on an X window manager (namely x monad) | 05:08:00 |
| andromeda | or better if I define ..WAYLAND and ..X11 then it automatically falls back | 05:12:45 |
| andromeda | but still only one frame | 05:12:56 |
| andromeda | this is really embarassing but I mixed up which exit code-style function return was good (==0) and bad (/=0) | 05:21:11 |
 iqubic (she/her) | So I have the Haskell package sbv listed as a dependency of my project in my Cabal file and then I'm pulling that in with cabal2Nix. For some reason, Nix is trying to pull in sbv-11.7 which is A) old and B) broken. Is there some way I can tell Nix to get version 13.3 for me? | 09:52:54 |
| iqubic (she/her) | https://hackage.haskell.org/package/sbv | 09:52:59 |
| iqubic (she/her) | { pkgs ? import <nixpkgs> {} }:
let
src = pkgs.nix-gitignore.gitignoreSource [] ./.;
myPkg = pkgs.haskell.packages.ghc912.callCabal2nix "aoc25" src {};
in
pkgs.stdenv.mkDerivation {
name = "aoc-shell";
buildInputs = [
myPkg.env.nativeBuildInputs
pkgs.cabal-install
pkgs.haskell.packages.ghc912.haskell-language-server
pkgs.z3
];
}
| 09:53:12 |
 toonn | I think you'll have to override the package. Probably best to check the Nixpkgs manual because it's tricky. | 10:04:22 |
| maralorn | iqubic if none of your dependencies need sbv you can get away with putting the override in the empty attrset at the end of your line 4. | 10:05:34 |
| maralorn | There might be a ...ghc912.sbv_13_3 attribute which you can use. | 10:07:32 |
| maralorn | Although it might also be broken without intervention. | 10:07:51 |
