| 1 Jul 2025 |
 roberth | So what we're left with is the "developer" use case | 12:06:15 |
 emily | it is "reasonably" pure since things are still addressed by hash but it seems to me the only way to get builds involving >40 GiB of assets without years of experimental work on the Nix end | 12:06:25 |
| roberth | For development, presumably you want a quick build, so making asset processing fine grained with a derivation per asset would be the thing to do | 12:06:59 |
 magic_rb | To clarify, i dont have an immediate use case for this. It would be nice, but so far i dont have a game id be developing lol | 12:07:17 |
|  sinan changed their profile picture. | 12:07:52 |
| magic_rb | So this was more something i wanted to look at personally, but it seems i severely underestimated the complexity | 12:09:11 |
| roberth | If you're ok with some eagerness for now, the complexity isn't so bad | 12:09:57 |
| roberth | This one's the easiest to implement, and it can follow the LFS pattern | 12:10:20 |
| magic_rb | Honestly even the eager version would be nice, currently it just leaves a bunch of dangling symlinks | 12:10:45 |
| magic_rb | So option one, "deference it completely and return the file contents" | 12:11:07 |
| roberth | yep | 12:11:16 |
| roberth | That one can follow the structure of the LFS implementation | 12:11:40 |
| magic_rb | Can it be done as a plugin or does it have to be done in tree? | 12:11:59 |
| magic_rb | While experimenting a plugin would be much easier | 12:12:10 |
| roberth | (oh, it quoted the whole message lol) | 12:12:11 |
| roberth | I don't feel like plugins are easier because I don't think libfetchers plugins have been done, but I could be wrong | 12:13:00 |
