| 22 May 2025 |
 puck | In reply to @emilazy:matrix.org
(using scopedImport to catch readFile takes 1.5× longer to eval :( ) (scopedImport doesn't cache imports the way import does; this is maybe a pretty big reason for the slowdown?) | 14:26:32 |
 emily | hmm I'd somewhat hope Nixpkgs doesn't import the same files over and over but maybe that's optimistic | 14:27:11 |
| emily | indeed it is, sort -u goes from 6186 to 4003 | 14:28:18 |
| emily | which is precisely a ratio that explains the slowdown | 14:28:28 |
| emily | I wonder if there's anything disgusting I can do to re-add the caching | 14:28:43 |
| emily | best idea I can immediately come up with is let imports = listToAttrs (map (filename: { name = filename; value = scopedImport env filename; }) enumerateEveryFileInNixpkgs); env = { import = filename: imports.${filename} or scopedImport env filename; …; }; or something | 14:32:28 |
| emily | and by best I mean horrible | 14:32:33 |
| emily | constant factors seem like they'd be brutal too | 14:32:43 |
| emily | the other thing is that I actually don't need to trace stuff in Nixpkgs… but I can't just avoid forwarding import = scopedImport env; to Nixpkgs, because Nixpkgs can import user code again (e.g. callPackage) | 14:36:23 |
| emily | I guess I could override lib.callPackageWith and hope there's no other important cases :) | 14:37:49 |
|  sbc64 joined the room. | 16:40:46 |
 Philip Taron (UTC-8) | Awesome news! Is there someone from the Nix core team on deck to make the nixpkgs PR, or would you like community support from (say) me there? | 17:59:48 |
