Haskell in Nixpkgs/NixOS | 691 Members | |
| For discussions and questions about Haskell with Nix, cabal2nix and haskellPackages in nixpkgs | Current Docs: https://haskell4nix.readthedocs.io/ | 138 Servers |
| Sender | Message | Time |
|---|---|---|
| 19 Oct 2025 | ||
| I noticed that we're packaging both .so and .a artifacts where Arch seems to only include the .so . Probably a naive question, but are we using those .a's? :) | 16:40:29 | |
| with https://github.com/NixOS/nixpkgs/commit/fffebd7398360d241c3e34f01af4813ef199e488 haskell.packages.ghc912.these seems deterministic, so that's promising! | 17:03:16 | |
| That PR is just the regular update of haskellPackages. We track Stackage. Stackage LTS is currently on GHC 9.10.3. So when we upgrade to GHC 9.12 is mostly dependent on when Stackage updates. We just updated to GHC 9.10 recently, so it will still take a while. Ofc, we can enable this flag for GHC 9.12+ already - but we won't build the big majority of haskell packages with it, yet. And we won't have insights into whether it might cause build problems, because we don't build the full package set for GHC 9.12, yet. | 17:33:01 | |
| Gotcha, makes sense | 17:56:09 | |
| it might be interesting to enable it by default for 9.12 - cache.nixos.org does appear to contain a bunch of packages.ghc912 packages (though it's not quite clear to me where they're built), so it might allow us to see build problems early | 20:18:58 | |
| 20 Oct 2025 | ||
| Would someone take a look at Breakage reproducible on both
I believe this is contributing to a breakage of Haskell Language Server | 04:38:28 | |
| No, the standalone hls plugin packages are deprecated, they were moved into the hls package | 06:17:09 | |
| Thanks! | 06:19:50 | |
In reply to @raboof:matrix.orgdid you measure performance impact | 06:59:59 | |
In reply to @raboof:matrix.orgyes | 07:00:18 | |
In reply to @raboof:matrix.org* did you measure performance impact? | 07:00:28 | |
In reply to @raboof:matrix.org* yes, dynamically linking executables means excessively large closure sizes | 07:01:25 | |
In reply to @sternenseemann:systemli.orgAs usual, separate outputs would be nice but potentially require a lot of effort to implement. :s | 08:17:03 | |
| 21 Oct 2025 | ||
| 04:51:49 | ||
| 10:36:16 | ||
| is cabal2nix not aware of build-tools-depends or do i need to blame flake-parts's haskell-flake? | 21:57:25 | |
| eldritchcookie: the latter I think | 23:13:21 | |
| * eldritchcookie: the former I think | 23:13:25 | |
| * eldritchcookie: the former I think (not aware) | 23:13:33 | |
| i did some digging and actually calling cabal2nix on my cabal package has an output which contains TestToolDepends = [tasty-discover]; so somebody is dropping that and it certainly isnt cabal2nix | 23:17:22 | |
| 22 Oct 2025 | ||
| for 'these' it does seem slower, but in the order of 'tens of milliseconds' on an ~11-second build. I tried a more substantial package (hoogle), that was about 2 seconds slower for a 46-second build (averages across 4 builds each). So measurable impact (but promising to see it did seem to have the desired effect for hoogle as well)... | 10:39:44 | |
| hm, im getting this from nixpkgs:
weird | 20:24:03 | |
| its an interesting failure, very, not helpful | 20:24:57 | |
| 23 Oct 2025 | ||
| might want to try 9.12 from recent nixpkgs | 17:23:06 | |
| pkgsCross.ghcjs.haskell.packages.ghc912 has cached miso and reflex-dom, which means a lot of other packages are also cached by being their deps | 17:23:38 | |
I get nix-build -A pkgsCross.ghcjs.haskell.packages.ghc912.ghcjs-base from cache on https://github.com/NixOS/nixpkgs/commit/c90b7f75f4e9d4dffcdc30261f565da1e261d468 which is just a few days old | 17:26:32 | |
| magic_rb: ^ | 17:26:42 | |
| I kind of gave up with ghcjs when it started giving cryptic errors so I moved my stack over to wasm | 17:27:18 | |
| js backend is recent enough I wouldn't bother much with anything older than 9.12 | 17:27:21 | |
| but yeah, wasm is very much an option | 17:27:59 | |