| 31 Jul 2025 |
 emily | this is unfortunate; .?rev=…# avoids it but is slow | 14:18:03 |
 raitobezarius | 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 | 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 | 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 | 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 | none | 14:40:22 |
| raitobezarius | except issues in lix tracker | 14:40:28 |
| raitobezarius | but it doesn't cover fully the scope | 14:40:32 |
| raitobezarius | the code is the most accurate first approximation of the technical debt | 14:40:42 |
| raitobezarius | 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 |
| emily | ah probably to match the createDirs on the build-dir path | 17:30:59 |
| raitobezarius | yes | 17:31:15 |
| emily | but that was not present before all this churn I think | 17:31:49 |
| emily | we only manage creating the dir in there because now it's owned by the daemon | 17:31:58 |
| emily | and nothing else creates it on Darwin | 17:32:02 |
| raitobezarius | what is your realization? | 17:33:23 |
| raitobezarius | like what do you think should be the right behavior? | 17:33:33 |
| emily | I just wanted to check I am not breaking anything by removing the call | 17:33:52 |
