| 31 Jul 2025 |
 WeetHet | Because on a path <-> string boundary the paths are devirtualised | 14:07:33 |
| WeetHet | So the nondeterminism leak is minimal | 14:07:51 |
| 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 |
