| 28 Nov 2025 |
 @acidbong:envs.net | the way to reproduce is to have environment.systemPackages = [pkgs.cachix]; | 16:27:44 |
| @acidbong:envs.net | it does help, but I want to have doc output from other packages | 16:28:24 |
| @acidbong:envs.net | * 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 |
| @acidbong:envs.net | it'll start like this:
these 279 paths will be fetched (160.57 MiB download, 1693.50 MiB unpacked):
/nix/store/i6kmc2cg12acc5kx55vpkxwb1a07a17s-Diff-1.0.2-doc
/nix/store/1aqpij0r645krf360sp91755gbr23g6k-OneTuple-0.4.2-doc
/nix/store/nfnj3wiv2hmiybkywz72749b7vy17hpj-QuickCheck-2.15.0.1-doc
/nix/store/19yjvfpkjxxcvi8kyvj21wk8qlf1qfy9-SHA-1.6.4.4-doc
/nix/store/lr0vzbpjqzxli3i255y6rxxmihh75ljx-StateVar-1.2.2-doc
/nix/store/0y1dvczs1hhnhq21fhx6gpv8jdswxcd3-adjunctions-4.4.3-doc
/nix/store/qi4r1j0mf1qrfxkzgdcd402gkm8g1dz5-aeson-2.2.3.0-doc
/nix/store/91hz94r3z28al926pj1z49nwd3a7l7xk-aeson-pretty-0.8.10-doc
/nix/store/1qzz56rc62qbcaz6735nfrz68llmzmn9-algebraic-graphs-0.7-doc
/nix/store/njypyw5wkzqjz8yg5h5jsc7fprhjacfq-amazonka-2.0-unstable-2025-04-16-doc
/nix/store/mhr4sj0rv8amf2df1bqa1p23r2zxwa4v-amazonka-core-2.0-unstable-2025-04-16-doc
...
| 16:31:40 |
| @acidbong:envs.net | 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 |
| @acidbong:envs.net | i seem to be not alone in this: https://github.com/NixOS/nixpkgs/issues/316768 | 17:07:32 |
| @acidbong:envs.net | maybe do that for all top-level standalone haskell packages? | 17:07:58 |
| @acidbong:envs.net | 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 |
| @acidbong:envs.net | not cachix's doc, but all its dependencies' docs | 17:12:27 |
| @acidbong:envs.net | * not only cachix's doc, but all its dependencies' docs | 17:12:37 |
| @acidbong:envs.net | 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 |
| @acidbong:envs.net | 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 |
| @acidbong:envs.net | In reply to @maralorn:maralorn.de
It is also kinda doubtful that the library docs of cachix are actually usefull docs for users of the executable. yeah, 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 |
| @acidbong:envs.net | yup, that works, opened 466253 | 18:19:51 |
 Alex | In reply to @sellout:matrix.org
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? It sounds like you should be using setup-depends: Cabal >= 3.10.3.0 because I think cabal-version is for the syntax and supported keywords in the Cabal package declaration.
https://cabal.readthedocs.io/en/3.4/cabal-package.html#pkg-field-custom-setup-setup-depends | 18:37:52 |
| sellout | I’m using setup-depends already (because of another Cabal bug), and yeah, that plus the Cabal override is my workaround, which /does/ work. It’s good to hear that that distinguishing the two references to Cabal is useful. But it does leave a few open questions 1. Nix (cabal2nix?) doesn’t pay any attention to setup-depends bounds (if I don’t override Cabal, it complains that it couldn’t load the plugin, not that the bound wasn’t satisfied – which is bad for discovery); 2. my Setup doesn’t actually have a direct dependency on Cabal, so it’s odd that I have to specify it at all, and 3. it still doesn’t help in the case that I would want to have a Cabal file with syntax from a Cabal newer than the one shipped with the corresponding GHC. | 19:44:22 |
