 | Haskell in Nixpkgs/NixOS | 709 Members |
| For discussions and questions about Haskell with Nix, cabal2nix and haskellPackages in nixpkgs | Current Docs: https://haskell4nix.readthedocs.io/ | 143 Servers |
| Haskell in Nixpkgs/NixOS | 709 Members |
| For discussions and questions about Haskell with Nix, cabal2nix and haskellPackages in nixpkgs | Current Docs: https://haskell4nix.readthedocs.io/ | 143 Servers |
| Sender | Message | Time |
|---|---|---|
| 28 Nov 2025 | ||
 linj | cannot reproduce. closure size of my cachix is only 155MiB
| 16:25:44 |
 @ghpzin:envs.net | You might disable documentation.doc.enable, if you do not want to pull them for any package. | 16:25:51 |
| @ghpzin:envs.net | You might disable documentation.doc.enable, if you do not want to pull them for any package in environment.systemPackages | 16:26:06 |
 Acid Bong | the way to reproduce is to have environment.systemPackages = [pkgs.cachix]; | 16:27:44 |
| Acid Bong | it does help, but I want to have doc output from other packages | 16:28:24 |
| Acid Bong | * it does help, but I want to have doc output from other packages, so not perfect | 16:28:31 |
| linj | interesting, let me try | 16:28:58 |
| Acid Bong | it'll start like this: | 16:31:40 |
| Acid Bong | actually, this seems more like a buildEnv issue than Haskell (it's just only Haskell that has doc outputs for every library out there) | 16:35:47 |
| linj | Acid Bong: Yeah, you are right. | 17:05:07 |
| linj | Maybe we should add a variant of cachix that uses justStaticExecutables instead of enableSeparateBinOutput | 17:05:47 |
| Acid Bong | i seem to be not alone in this: https://github.com/NixOS/nixpkgs/issues/316768 | 17:07:32 |
| Acid Bong | maybe do that for all top-level standalone haskell packages? | 17:07:58 |
| Acid Bong | although Nixfmt is fine already | 17:09:12 |
| linj | No, I do not think they are the same issue. Actually, from a certain perspective, your "issue" is not an issue. It works as expected: you have documentation.doc.enable = true so cachix doc is pulled in | 17:10:44 |
| linj | because it uses justStaticExecutables already | 17:11:39 |
| Acid Bong | not cachix's doc, but all its dependencies' docs | 17:12:27 |
| Acid Bong | * not only cachix's doc, but all its dependencies' docs | 17:12:37 |
| Acid Bong | and the second part is exactly undesirable | 17:12:48 |
| linj | haha, its doc depends on its dependencies' doc | 17:15:01 |
| linj | You can go to its dependencies' doc by clicking hyperlinks from its doc | 17:16:39 |
| Acid Bong | ah, I thought buildEnv pulls docs recursively | 17:16:41 |
| linj | It's a feature! | 17:16:44 |
| 29 Nov 2025 | ||
 maralorn | linj: re: justStaticExecutables. This is interesting. I have been advocating to replace justStaticExecutables with enableSeparateBinOutput because I was not aware of any downsides of the later (when it works. It can cause build errors because of problems with cabal). And I always found it more elegant to reuse the library output instead of just deleting it. No I am wondering whether that was a bad direction. | 00:09:44 |
| maralorn | * linj: re: justStaticExecutables. This is interesting. I have been advocating to replace justStaticExecutables with enableSeparateBinOutput because I was not aware of any downsides of the later (when it works. It can cause build errors because of problems with cabal). And I always found it more elegant to reuse the library output instead of just deleting it. Now I am wondering whether that was a bad direction. | 00:09:49 |
| maralorn | It is also kinda doubtful that the library docs of cachix are actually usefull docs for users of the executable. | 00:10:33 |
| Acid Bong | In reply to @maralorn:maralorn.deyeah, cuz if they want Cachix the library, they can get haskellPackages.cachix (or shellFor {packages = h: [h.cachix];}) | 05:27:15 |
 sterni | Wolfgang Walther: I could make a cabal2nix release for the next iteration, so end users on stable cabal2nix can benefit from _type etc. Not a big priority since it's somewhat fringe, but would be good to do eventually | 14:46:16 |
 Wolfgang Walther | No objections! | 18:03:35 |
 sellout | I’m having an issue with using a cabal-version other than the one included with GHC. There is a Cabal bug that was fixed in 3.10.3. I updated my Cabal files to include cabal-version: 3.10.3, but my packages support back to GHC 9.6.1 (and the first with Cabal 3.10.3 is GHC 9.8.3). I’ve tried overriding Cabal/Cabal-syntax/cabal-install for GHCs older than 9.8.3, but I still get the complaint “Unsupported cabal-version 3.10.3.” Interestingly, the workaround I managed to find is if I override Cabal to 3.10.3.0, but let cabal-version be set to something older, it works. Maybe this is actually the correct thing – the Cabal file can be parsed with an older Cabal, but Setup requires the non-broken one? | 18:12:15 |