| 18 Mar 2026 |
Alex | Right, so haskellPackages.ghc is the same as buildPackages.ghc? | 05:48:13 |
alexfmpe | In reply to @woobilicious:matrix.org I have a questions about the general architecture of haskellPackages, does hackage have dep cycles? and how do you deal with them when generating the package list? I'm working on a little project that generates a package list from a foreign source, but it has cycles, and I'm kinda clueless on how to break cycles up without just removing all dependencies You can have package cycles, just not component cycles. For packages A,B it's valid to have libA <- libB <- testA | 05:50:04 |
alexfmpe | In cabal packages that is | 05:50:24 |
alexfmpe | haskellPackages in particular is 'wrong' in that it generates one derivation per package, not per component | 05:50:54 |
alexfmpe | So we have to manually break cycles for a bunch of test packages with dontCheck | 05:51:15 |
alexfmpe | Search for 'cycle' or so in configuration-common.nix for examples | 05:51:40 |
alexfmpe | `nix-build --show-trace` can help find specific cycles since it shows the call stack | 05:52:47 |
alexfmpe | In reply to @alex:tunstall.xyz Right, so haskellPackages.ghc is the same as buildPackages.ghc? I think so, though it seems completely backwards to me | 05:53:21 |
alexfmpe | I'd expect haskellPackages.foo to always have the same host platform | 05:53:46 |
alexfmpe | * I'd expect pkgsCross.foo.haskellPackages.bar to always have 'foo' as same host platform for all 'bar' | 05:54:28 |
alexfmpe | But bar=ghc acts special | 05:54:53 |
alexfmpe | In reply to @alexfmpe:matrix.org haskellPackages in particular is 'wrong' in that it generates one derivation per package, not per component Or rather, cabal2nix is wrong, and haskellPackages is based on throwing cabal2nix at hackage | 05:55:40 |
Alex | I believe this is due to how ghc is threaded through haskellPackages. So that mkDerivation can find it, it is bound to ghc, but this only works well for native.
It also has weird consequences when you try using other compilers, where you can e.g. end up with haskellPackages.ghc being MicroHs. | 06:08:19 |
woobilicious | Ahh thanks for the feedback, I don't think manual intervention is practical here, the more I think about it, the more it might be easier to just build dirivation per package, with no "real" dependencies, and then de-duplicate strings some way to prevent infinite loops. | 07:45:37 |
| cookies joined the room. | 11:01:33 |
linj | Just found a new nix interpreter implemented from scratch in Haskell https://github.com/Novavero-AI/nova-nix. Any comments? | 11:05:00 |
chreekat | Big if true | 11:20:30 |
alexfmpe | Author has been announcing it in couple rooms | 11:29:16 |
alexfmpe | Seems like AI slop | 11:29:25 |
alexfmpe | > Hand-rolled recursive descent parser for the full Nix expression language. 13 precedence levels, 18 AST constructors, | 11:29:30 |
alexfmpe | "Now with 30% more precedence levels. Buy 3, take 4" | 11:30:37 |
alexfmpe | * "Now with 30% more precedence levels. Buy 3, get 4" | 11:31:20 |
magic_rb | It is AI slop | 11:32:48 |
magic_rb | Its fully slop-coded, top to bottom | 11:33:02 |
woobilicious | Nothing screams "Haskell" coding like using a probalitistic LLM... | 11:33:04 |
magic_rb | Indeed, i have interest in reviewing or using slop-coded code in my free time. The code produced is always subtly wrong and weirdly organized, I've better things to do with my life | 11:34:57 |
magic_rb | * | 11:35:09 |
Morj | Nothing screams "Haskell" coding like using a probalitistic LLM...
If it compiles it works, right | 12:00:07 |
Morj | I remember in chat they were going to use it to distribute their games for windows. If it works for that, that would be cool if horrifying | 12:09:11 |
Morj | * I remember in chat they were going to use the new nix impl to distribute their games for windows. If it works for that, that would be cool if horrifying | 12:09:20 |