| 28 Nov 2025 |
 Acid Bong | i did, NixOS still pulled doc outputs
weird thing about Nixpkgs' outputs in general: they're all reachable from one another (meaning ffmpeg.dev is the same as ffmpeg.lib.bin.dev.bin.dev)
my workaround was to use symlinkJoin, but that looked kinda convoluted | 16:20:50 |
 linj | cannot reproduce. closure size of my cachix is only 155MiB
nix path-info -Sh $(nix build github:nixos/nixpkgs/nixos-unstable#cachix --print-out-paths)
/nix/store/k77ik2kcv82y2qvv3lg6x4r2cfwjbix2-cachix-1.9.1-bin 155.8 MiB
| 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:
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 |
| 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 |
