| 31 Jul 2025 |
 emily | they're not really | 14:12:16 |
| emily | just hashing is meaningfully faster | 14:12:28 |
 WeetHet | I don't know if nar-hash can be constructed iteratively so that you only need to rehash changed files | 14:13:14 |
| emily | see https://github.com/NixOS/nix/pull/13225#pullrequestreview-2858935020 for discussion, particularly the later review subthread | 14:13:17 |
| emily | I think roberth has it right that you want an opaque path type | 14:13:26 |
| emily | though that is of course a big lift | 14:13:30 |
| emily | NAR hashing is also just bad… but that's another matter | 14:13:50 |
| emily | anyway | 14:14:00 |
| emily | does anyone have feelings about /nix/var/nix/b instead of /nix/var/nix/builds? | 14:14:07 |
| emily | I have implemented most of the thing to fix the Unix socket length issue | 14:14:24 |
| emily | with /b/ we end up below the previous average length of a build directory | 14:14:33 |
| emily | with /builds/ we are still slightly above | 14:14:42 |
| emily | though if you count path normalization i.e. /private/tmp/… which I think a lot of things are doing behind the scenes we are ahead even with /builds/ | 14:14:53 |
| WeetHet |
Path equality and ordering (as observable to users) must remain identical
I've changed my opinion on this, though I'm not sure if there are really no usecases for comparing paths
| 14:15:15 |
| WeetHet | But it would be interesting to go over github and just see if anyone ever compares paths | 14:15:38 |
| emily | forbidding path comparison is precisely what a more opaque path type would achieve without breaking the language guarantees | 14:16:27 |
| emily | it has other nice advantages too (you can do objcap stuff) | 14:16:39 |
