!RbXGJhHMsnQcNIDFWN:nixos.org

Haskell in Nixpkgs/NixOS

677 Members
For discussions and questions about Haskell with Nix, cabal2nix and haskellPackages in nixpkgs | Current Docs: https://nixos.org/manual/nixpkgs/unstable/#haskell | Current PR: https://github.com/nixos/nixpkgs/pulls?q=is%3Apr+is%3Aopen+head%3Ahaskell-updates | Maintainer Docs: https://github.com/NixOS/nixpkgs/blob/haskell-updates/pkgs/development/haskell-modules/HACKING.md | More Nix: #community:nixos.org | More Haskell: #haskell-space:matrix.org | Merger Schedule: https://cloud.maralorn.de/apps/calendar/p/H6migHmKX7xHoTFa/dayGridMonth/now | Join #haskell.nix:libera.chat for question about the alternative haskell.nix infrastructure133 Servers

You have reached the beginning of time (for this room).


SenderMessageTime
22 Sep 2025
@maralorn:maralorn.demaralorn* Well, I mean anything that we want to do we can obviously do on the branch. No need to stop working. I was just thinking that it might not be necessary to do the cherry-picks.12:29:03
@wolfgangwalther:matrix.orgWolfgang WaltherI'm just worrying about merge conflicts that we would have to resolve later. By picking the commits now, we can probably avoid most of them.12:33:01
@wolfgangwalther:matrix.orgWolfgang WaltherBut maybe there won't be too many, if we don't have too many changes in the cycle anyway.12:33:21
@sternenseemann:systemli.orgsterniI think it does make sense also just to have visibility on those packages as well12:34:11
@sternenseemann:systemli.orgsternibut may be inconsequential if staging-next is quick…12:34:23
@maralorn:maralorn.demaralornI mean, tbf. nixpkgs commit history is a mess anyway. So we can probably just do it …12:34:58
@sternenseemann:systemli.orgsternihttps://github.com/NixOS/nixpkgs/pull/443159 can also go into haskell-updates12:54:47
@sternenseemann:systemli.orgsterniI think half of all haskell related commits from the last two months exist twice already12:55:26
@maralorn:maralorn.demaralornYou would probably have had it easier to convince me in this discussion if you had informed me that one of the PRs not being able to merge because the missing cherry-picks mad conflicts more likely was mine.18:01:25
23 Sep 2025
@a-kenji:matrix.orgkenji changed their display name from a-kenji to kenji.10:39:01
@teoc:matrix.orgteo (they/he)Is there an easy way to create a dev shell where I can use GHC with the llvm backend? Ideally without having to recompile ghc12:25:26
@teoc:matrix.orgteo (they/he)Oh wait maybe it's fine with stuff just being on the PATH12:27:39
@teoc:matrix.orgteo (they/he)it spews some warnings about versions but continues anyway12:27:54
@sternenseemann:systemli.orgsterni teo (they/he): (ghc.withPackages.override { useLLVM = true; }) (p: [ … ]) it's even documented :-) 13:26:01
@sternenseemann:systemli.orgsterni though you still have to pass -fllvm that's a misleading name (thanks to me) 13:26:23
@teoc:matrix.orgteo (they/he)Nice thanks! Yeah it's a bit silly. Hopefully we will have better ways to specify these things soon.13:36:24
@teoc:matrix.orgteo (they/he)* Nice thanks! Yeah it's a bit silly. Hopefully we will have better ways to specify these things soon (through like the toolchain specification or something).13:37:07
@alex:tunstall.xyzAlex
In reply to @teoc:matrix.org
Nice thanks! Yeah it's a bit silly. Hopefully we will have better ways to specify these things soon.
The replaceStdenv stuff already exists, but it won't save you from rebuilding GHC.
19:02:13
@alist:matrix.orgyliceee changed their display name from λlice to yliceee.20:01:46
@alist:matrix.orgyliceee changed their profile picture.20:02:26
@alist:matrix.orgyliceee changed their profile picture.20:04:24
24 Sep 2025
@ashinnv:matrix.orgMagnolia Mayhem changed their profile picture.14:46:16
@ashinnv:matrix.orgMagnolia Mayhem changed their profile picture.19:45:13
25 Sep 2025
@bglgwyng:matrix.orgbglgwyng If a package is not affected by foo-package.override { random = ... }, which means random is not overridden but remains as the one in haskellPackages, what are some things I can try to investigate further 08:53:03
@bglgwyng:matrix.orgbglgwyng The package overrides other than random works well 08:53:22
@bglgwyng:matrix.orgbglgwyng * If a package is not affected by foo-package.override { random = ... }, which means random is not overridden but remains as the one in haskellPackages, what are some things I can try to investigate further? 09:00:44
@maralorn:maralorn.demaralornI can’t think of anything straightforward. Best ideas is a) there is a second override which negates your first override b) you are mistakingly not actually passing a different random. I can think of wilder theories, but they will be even more likely to be wrong.09:30:59
@bglgwyng:matrix.orgbglgwyng

I tried overriding it at the last place like,

{ packages.hip = config.cabal-projects.default.packages.hip.override { random = config.cabal-projects.default.packages.random; }; }

but still same

09:32:13
@sternenseemann:systemli.orgsterni bglgwyng: Haskell dependencies need to be propagated, so any given package sees its transitive Haskell dependency closure. random is pretty common, so probably somewhere the non overridden random is visible. Cabal is free to pick any version within bounds. 10:58:17

Show newer messages


Back to Room ListRoom Version: 6