Haskell in Nixpkgs/NixOS | 720 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 | 143 Servers |
| Sender | Message | Time |
|---|---|---|
| 13 Sep 2025 | ||
| I assume more folks than me want to use Nix on CircleCI | 14:46:10 | |
| Now I'm scared about arithmetic regressions in 9.10.3… https://github.com/Bodigrim/arithmoi/issues/223 | 14:58:30 | |
| so far nothings else like that happened, though | 14:59:08 | |
| 17:21:40 | ||
| 17:31:40 | ||
| 17:32:21 | ||
| was nothing apparently | 22:07:02 | |
| 14 Sep 2025 | ||
| 03:18:20 | ||
| 08:39:56 | ||
| 15 Sep 2025 | ||
Can we override argument passed to cabal2nix result with haskellPackages.override?For example, if I want to replace native zlib used by haskell package zlib, I can use overrideCabal to modify librarySystemDepends.However, is it possible to just override the value passed to cabal2nix, which is a lambda with arguments { mkDervation, base, ..., zlib}? | 03:38:50 | |
In reply to @bglgwyng:matrix.org cabal2nix produces a Nix script. If you mean overriding what gets passed to that script when you use callCabal2nix or callPackage then the answer is yes: put it in the attrset argument. | 03:44:27 | |
overrideCabal also works as with any other Haskell package because cabal2nix uses the same builder. | 03:46:00 | |
Yes. but haskellPackages.override { overrides = self: super: zlib = super.zlib.override { zlib = my-zlib}} doesn't work, since super.zlib is not the lambda argument, but the result of callPackages. So it's late. | 03:54:48 | |
From my understanding, when we use nixpkgs haskellPackages | 03:55:27 | |
* From my understanding, when we use nixpkgs's haskellPackages, we usually deal with the result of callPackage cabal2nix-lambda rather than cabal2nix-lambda itself? | 03:56:00 | |
this is from hackage-pacakges.nix, and I'm not sure if I have any chance to override | 03:57:11 | |
| So you want to be able to e.g. add extra arguments to the IIRC that's possible with I'm having trouble understanding why overriding the result is insufficient in your case. | 04:02:48 | |
Hmm, I tried such a thing splitmix = super.splitmix.override { testu01 = null; }; but it didn't work. | 04:06:32 | |
| splitmix's definition is like
| 04:07:13 | |
To provide the context, I'm not using the vanilla haskellPackages, but the generated one for my purpose. | 04:08:38 | |
I was trying to handle "error: function 'anonymous lambda' called without required argument 'testu01'" this error message, by passing testu01 = null just like hackage-packages.nix does. | 04:09:24 | |
Of course I can do it with the cabal2nix expression, but I was wondering if I can do the same thing when callPackage is already applied. | 04:10:09 | |
If any approach simliar to splitmix = super.splitmix.override { testu01 = null; } is possible, it would be really helpful. | 04:10:53 | |
| ah maybe I made a stupid mistake | 04:16:01 | |
it seems that the result of callCabal2Nix is not overridable, and I should wrap it manullay to make it overridable. | 04:16:42 | |
Yes, the vanilla pkgs.haskellPackages.* things are overridable and my callCabal2Nix results are not overridable. And I just found that make-package-set applies makeOverridable manullay. | 04:19:02 | |
In reply to @bglgwyng:matrix.orgAt the very least, most of the functions from haskell.lib and haskell.lib.compose should be able to override it (try looking at how they do it?)That is, unless you use things like buildFromSdist which IIRC prevent further overrides because of how they work. | 10:56:42 | |
| Seems like MicroHs is getting more serious about being usable for general purpose stuff, could maybe be interesting to try and add a microhs package set for variety. https://discourse.haskell.org/t/microhs-and-hackage/12916. However, the approach Lennart is taking is a bit questionable. For packages that don't accept MicroHs patches, MicroCabal automatically replaces them with an entirely different package (e.g. random-mhs instead of random). The package descriptions seem to rely on this as well, e.g. you can't build the random-mhs test suite with GHC/Cabal since it declares a dependency on random instead of random-mhs (though maybe that's just a mistake). | 12:23:43 | |
| we talked about this recently and I suggested a package set would be interesting for exploring future GHC bootstrap | 12:26:04 | |
| especially since we can have MicroHs bootstrap from hugs | 12:26:15 | |