Haskell in Nixpkgs/NixOS | 729 Members | |
| For discussions and questions about Haskell with Nix, cabal2nix and haskellPackages in nixpkgs | Current Docs: https://haskell4nix.readthedocs.io/ | More Nix: #community:nixos.org | More Haskell: #haskell-space:matrix.org | 146 Servers |
| Sender | Message | Time |
|---|---|---|
| 30 Dec 2025 | ||
I think writing code that simultaneously supports __structuredAttrs true and false is somewhat nonsensical especially when code is written in a way that it has an extra API to work around regular argument splitting limitations. | 12:31:10 | |
If __structuredAttrs is truly the way to go and there are no potentially showstopping issues, I'd rather redesign the GHC expression and generic builder in a breaking way and always use structured attrs. | 12:32:09 | |
| it'd help mkDerivation, actually, in some ways. | 12:32:21 | |
I must say that I personally find __structuredAttrs a bit icky since it's not exactly simple nor has clean separation of concerns, but oh well… | 12:33:43 | |
| From the interpreter side, all (known) issues with structuredAttrs should be solved since we bumped min version for Nixpkgs - we are not concerned anymore with any Nix versions that had problems there. structuredAttrs is certainly the way to go in the future, it's just a matter of time (and effort) to get the migration done. The reason to support both with/without structuredAttrs is purely the transition period while not every expression supports them. This is mostly relevant for generic builders / setup hooks and such, which might not be able to tell in advance whether their downstream consumers will be using structuredAttrs or not. The GHC expressions can certainly all be rewritten to consistently use structuredAttrs, no problem with that. Forcing the haskell generic builder to always use structuredAttrs would have an impact of out-of-tree users using that builder. If we're OK with a breaking change in that way, then yes, the best way is to consistently use structuredAttrs here, too. | 12:37:55 | |
| Is there some ressource about what structuredAttrs does and what it solves? | 12:53:28 | |
| Nix manual I assume | 12:54:05 | |
| https://nix.dev/manual/nix/2.19/language/advanced-attributes#adv-attr-structuredAttrs | 12:55:05 | |
| 12:59:17 | ||
| I find this blog very helpful https://nixos.mayflower.consulting/blog/2020/01/20/structured-attrs/ | 13:52:51 | |
| We probably (also) have some new Haskell failures on master now with gcc15, so that may be worth checking up on in the coming days. | 18:32:11 | |
| 23:09:43 | ||
| 31 Dec 2025 | ||
| 22:18:05 | ||
| 1 Jan 2026 | ||
| 02:52:05 | ||
| 02:53:10 | ||
| 4 Jan 2026 | ||
| 17:12:55 | ||
| 17:14:40 | ||
| 5 Jan 2026 | ||
| 17:56:26 | ||
| 6 Jan 2026 | ||
| So … What is the 2026 way of running doctests as part of my nix-build? | 12:36:15 | |
| I'm trying to work on
| 14:44:48 | |
| Might Cabal be picking up a different GHC? | 14:46:14 | |
It doesn't look like it, cabal --verbose build says
Running: /nix/store/a8h81f4wc2nc8qgrfsxvgfd8has0xh3r-ghc-9.6.3/bin/ghc --print-global-package-db
and the flake says ghc963 | 14:48:51 | |
| Apparently cabal-doctest works. Couldn’t get doctest-discover to run. | 17:19:16 | |
| But I still very much have no idea what I am doing … | 17:19:33 | |
| 7 Jan 2026 | ||
| 00:25:15 | ||
| Hello there, while having a conversation with my coincidentally named counterpart (i remember that), I discovered that haskell packages set has a at least a few packages that we should really not ship, as they has been removed after a report on the [https://github.com/haskell-infra/hackage-trustees/issues/132](hackage-trustees ' Spam/fraudulent issue) While both examples sigmaSquadron gave me are marked as broken, this is due to dependency mismatch, not that the source is gone, because we have it cached. | 00:30:52 | |
| Yeah, it's probably not ideal that the channels just randomly have sources for known fraudulent software. | 00:35:11 | |
Does anyone have experience with pkgsCross.ghcjs? I'm trying to build a package that indirectly depends on zlib, and getting the following error: no C compiler provided for this platformI can trace the error to here: https://github.com/NixOS/nixpkgs/blob/492f8a5b3855f5d5f3fa4d096acb073ec7c86e17/pkgs/stdenv/cross/default.nix#L118 I think I should be able to use emscripten as a C compiler, any idea how I could wire that up to get zlib to build? | 08:43:37 | |
| 15:34:54 | ||
evening. what's the current status of Cabal not seeing deps provided by shellFor? I see some suggest v1-* commands to workaround, but they both fail for me:shell.nix seems to have the necessary toolsobviously generating a package recipe and building with Nix works, but i'm using the shell purely to cabal run or cabal repl the respective packages, which doesn't seem to work without fetching the deps from Hackage | 18:00:43 | |