| 31 Jul 2025 |
 WeetHet | I don't love it but realistically it's not as big of a trade off as it can seem in the first place | 14:09:10 |
 emily | tbf, lazy trees prevents torn writes | 14:10:47 |
| emily | though of course nondeterminism in pure eval mode sans IFD is not really acceptable | 14:10:57 |
| emily | (and does not really seem necessary) | 14:11:07 |
| WeetHet | The real issue is that calculating the path and copying the source to the store are computationally very similar tasks | 14:11:53 |
| 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 |
 raitobezarius | In reply to @emilazy:matrix.org
tbf, lazy trees prevents torn writes I might not be using Flakes enough but I never saw a torn writes and I probably run the most experimental filesystem stack on my main system with the one of the largest stores around (and I hit most of the store bugs :D) | 14:16:41 |
| emily | that is a lower level of torn write than I mean | 14:16:56 |
| WeetHet | Although you don't need to use nar-hashes to compare paths | 14:16:58 |
| WeetHet | You can use a cache that can be cached | 14:17:18 |
| WeetHet | * You can use a hash that can be cached | 14:17:26 |
| emily | and tbf default flakes behaviour does not prevent it either. what I mean is that -f . cannot achieve the same as .?rev=HEAD because you can end up evaluating an inconsistent state | 14:17:26 |
| emily | where a.nix is the old version and b.nix is the new version | 14:17:33 |
| raitobezarius | In reply to @weethet:catgirl.cloud
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
Burden of proof is not on me ;-) | 14:17:35 |
