| 31 Jul 2025 |
 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 |
| WeetHet | https://blog.replit.com/tvix-store | 14:27:06 |
| raitobezarius (DECT: 7248) | having a compat layer is very possible but all paths converges to Rome: technical debt needs to be paid to get there | 14:27:39 |
| raitobezarius (DECT: 7248) | and any technical debt we predict ends up being 30x | 14:27:52 |
| WeetHet | In reply to @raitobezarius:matrix.org
having a compat layer is very possible but all paths converges to Rome: technical debt needs to be paid to get there Is there any tracker/doc on the current state of technical debt? | 14:39:54 |
| raitobezarius (DECT: 7248) | none | 14:40:22 |
| raitobezarius (DECT: 7248) | except issues in lix tracker | 14:40:28 |
| raitobezarius (DECT: 7248) | but it doesn't cover fully the scope | 14:40:32 |
| raitobezarius (DECT: 7248) | the code is the most accurate first approximation of the technical debt | 14:40:42 |
| raitobezarius (DECT: 7248) | it's only an approximation because there's hidden things that cannot be seen by understanding the code well :^) | 14:40:59 |
| emily | raitobezarius: do you remember why you try to explicitly create the global temporary directory in fd35e86fc5a7f3c13512a12e31145640cde442b3? no other code path does it, so I think having a nonexistent temp-dir is broken anyway | 17:29:56 |
