| 1 Jul 2025 |
 fzakaria | oh man | 03:05:34 |
| fzakaria | replacing bison/yacc would be such a big development boost i think; | 03:05:44 |
 djacu | Hey Nix Team
In case you haven't seen the recent post on discourse, the Marketing Team is preparing this year's community survey. I am reaching out to teams to see if there are any questions they would like to add to the survey to better serve the work you all do. More details in the post linked below.
https://discourse.nixos.org/t/community-feedback-requested-2025-nix-community-survey-planning/66155 | 03:27:54 |
 Robert Hensing (roberth) | This would be similar to LFS support, iiuc, which is already implemented | 11:19:06 |
 magic_rb | In reply to @joerg:thalheim.io
how would this be used with nix? Yeah, as robert said, with the current lack of support, if you have a repository with annex you end up with a bunch of dangling symlinks | 11:26:49 |
| magic_rb | In reply to @roberthensing:matrix.org
This would be similar to LFS support, iiuc, which is already implemented Its important to not resolve the symlink but just repoint them to the store. But yes, if base the code on git lfs | 11:27:18 |
| Robert Hensing (roberth) | magic_rb: Ohh the keys can be arbitrary and dependent on the annex backends? Seems like it will be hard to be sure that it's reproducible then - impossible if we want fully general support for it | 11:32:12 |
| magic_rb | In reply to @roberthensing:matrix.org
magic_rb: Ohh the keys can be arbitrary and dependent on the annex backends? Seems like it will be hard to be sure that it's reproducible then - impossible if we want fully general support for it Wdym keys, so the way it works is that there are symlinks checked into git which point into .git/annex/... and the keys there are sha256 hashes of the annexed file content always. So the backend doesnt matter. | 11:39:55 |
| magic_rb | If the annexed file isnt in the local annex store, the symlink will be dangling and then nix should throw an error ideally. To make it not do that one much do git annex get path/to/symlink which will copy the file into the local annex | 11:40:47 |
| Robert Hensing (roberth) | I started with this very high level description here, which suggests that the key can be anything | 11:40:52 |
| Robert Hensing (roberth) | if it's always sha256, or at least in practice, we can rely on that property to do the same thing we do for LFS | 11:41:12 |
| Robert Hensing (roberth) | (or similar if we want it to be a symlink) | 11:41:27 |
| magic_rb | Oh yeah okay backends | 11:41:45 |
| magic_rb | Damn didnt know there was that too | 11:41:54 |
| magic_rb | We could enforce a blessed set of backends yeah | 11:42:08 |
| Robert Hensing (roberth) | Partial support can be great if virtually everyone uses the SHA256 stuff | 11:42:15 |
| Robert Hensing (roberth) | yea | 11:42:19 |
| magic_rb | If its blake2 cant we sha256 hash the blake2 hash, or is that a horrible idea | 11:42:45 |
| Robert Hensing (roberth) | Probably a symlink to a synthetic .git/annex directory is preferable | 11:42:52 |
| magic_rb | In reply to @roberthensing:matrix.org
Probably a symlink to a synthetic .git/annex directory is preferable Id say that each annexed object should be a separate store path | 11:43:15 |
| magic_rb | You dont want to be copying 40GB every time a single image changes | 11:43:25 |
| Robert Hensing (roberth) | True, but we shouldn't be copying those store paths in the first place | 11:43:50 |
| Robert Hensing (roberth) | And if we do, they should match the non-Nix layouts | 11:44:02 |
| Robert Hensing (roberth) | Currently there's not much of a connection between libfetchers fetchers and the store layer, so putting it in the store is more complicated than putting it in .git/annex, fwiw | 11:44:27 |
| magic_rb | Wait so we just tell nix to include .git/annex during eval? | 11:44:57 |
| Robert Hensing (roberth) | (copying to the store only happens at the end of fetchTree and not within the individual source accessors) | 11:45:02 |
| magic_rb | Okay im lost lol | 11:45:17 |
| magic_rb | We do have to copy for a build still no? | 11:45:50 |
| Robert Hensing (roberth) | So we have the sources accessor objects that behave like very simple virtual file systems, and we plan to use them directly instead of copying everything to the store all the time | 11:46:11 |
| Robert Hensing (roberth) | They can implement operations like readDirectory or readFile as they please, so the git accessor with annex enabled could add a .git and .git/annex to what it returns, and then do whatever is necessary to return the contents of that | 11:47:31 |
