| 14 Oct 2025 |
 emily | the feature detection is precisely what caused the hash divergence. | 16:37:31 |
 WeetHet | Well yes, but how did the original PR even get accepted if it would cause different results on 2.18 and whatever the current version of nix is | 16:39:09 |
| emily | how would that be tested? | 16:39:58 |
| emily | Nix 2.18 is EOL | 16:40:06 |
| emily | https://github.com/NixOS/nixpkgs/pull/451926 will check hashes of Lix vs. Nix, but has not been implemented yet, that is how this was found | 16:40:26 |
 Qyriad | not if we accept hash = { algo, format, digest }; in FODs too, right? | 17:43:09 |
| emily | not sure what you mean | 17:45:04 |
| emily | I mean that if { algo, format, digest } is considered a "first-class" thing the implementation is consuming then it doesn't seem so weird to have a built-in that converts it at that point | 17:45:26 |
| emily | (the other potential use-cases like producing Nix32 filenames and converting lock file formats would remain regardless) | 17:45:44 |
| Qyriad | Filenames and lockfiles are a point in favor, but if the implementation consumes { algo, format, digest } in any form then you specifically wouldn't need to convert between them, no? | 17:46:54 |
| emily | I am not saying that you would need to convert them to pass them to a FOD fetcher. I'm saying that if the objection to a convertHash is "this is doing too much because these structured hashes aren't really a first-class implementation concept", but then you add support for structured hashes to FODs, then they are a first-class implementation concept and it doesn't seem too weird to have a conversion built-in for them. | 17:50:30 |
| emily | (and then that conversion built-in would be useful for the other use caess) | 17:50:41 |
| Qyriad | Ahh | 18:00:08 |
| * Qyriad nods | 18:00:10 |
| emily | is there actually a reliable way to feature detect NULs in strings currently? | 19:29:19 |
| emily | everything I can think of would abort in current Nix versions | 19:29:33 |
 jade_ | sounds like we need builtins.features real bad? | 19:39:21 |
| emily | it could just be a boolean | 19:40:30 |
 raitobezarius | detect NULs in a string OR detect NUL support in strings? | 19:40:37 |
| emily | builtins.nulBytesInStrings or false | 19:40:39 |
| jade_ | yes, that's what builtins.features is for :) | 19:40:40 |
| raitobezarius | i read the question in a different way | 19:40:41 |
| emily | fair enough | 19:40:49 |
| jade_ | we should not pollute the builtins namespace itself | 19:40:50 |
| raitobezarius | i thought this was about builtins.doesItHaveSomeNuls s | 19:40:51 |
| emily | no, it's about being able to portably use NUL bytes | 19:41:10 |
| jade_ | the only reason we don't have builtins.features is cuz nobody had time to do it yet | 19:41:20 |
| Qyriad | does it need any further design work or anything? | 22:10:45 |
| 15 Oct 2025 |
 helle (just a stray cat girl) | we are having a laugh/cry at the CI pipeline due to a merge requiring a rebase and that requiring a CI pass, it's an understandable problem, but we missed the window due to us having a migraine | 09:23:17 |
| raitobezarius | Soon, merge queue | 09:58:31 |
