| 31 Jul 2025 |
 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 (DECT: 7248) | 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 (DECT: 7248) | 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 |
| emily | because a.nix and b.nix change after a.nix starts to be read and evaluated | 14:17:41 |
| emily | but before b.nix is imported | 14:17:44 |
| emily | this is unfortunate; .?rev=…# avoids it but is slow | 14:18:03 |
| raitobezarius (DECT: 7248) | In the end, what lazy trees aims to achieve is a virtual filesystem and we want this certainly, but I don't think tacking it off this way is meaningful or useful | 14:18:24 |
| emily | (I won't comment on the flake "worktree contents but only files that are in the index" behaviour because it's incoherent, of course) | 14:18:37 |
| emily | (OTOH, Jujutsu @ is a much more coherent version of the same basic aim hence https://git.lix.systems/lix-project/lix/issues/799) | 14:18:58 |
| raitobezarius (DECT: 7248) | If people truly wants lazy trees "that way" on Lix, this is for an out of tree distribution rather than Lix itself
Flakes compat offers a path forward for those who have giga-enormous monorepos at work and needs to avoid the expensive copies but want to keep the flakes semantics and wants to know how to diff things (which is something you should anyway know how to do).
Once we paid enough technical debt, we can have slowly a proper VFS IMHO | 14:19:53 |
| emily | to be clear I don't think Lix should implement lazy trees esp. at present | 14:20:19 |
| emily | I think there is some value to the basic highest-level idea of lazy trees over -f . | 14:20:35 |
| emily | but I agree that proper VFS is the way | 14:20:39 |
| emily | you do still run into questions around NAR hashing and so on | 14:20:56 |
| WeetHet | Is it impossible to get rid of NAR hashes altogether and just have a compat layer as snix does? | 14:23:31 |
| WeetHet | Or even just use snix-store altogether | 14:25:36 |
| emily | the problem is that it is exposed to the language | 14:26:24 |
