| 14 Oct 2025 |
 raitobezarius | OK, I wondered if you as a Nixpkgs core team person, had any idea of a timeline given the demand | 16:29:45 |
| raitobezarius | But unknown timeline works for me, I will register this as low priority (aka when I'm bored) | 16:29:55 |
 emily | sha256 = …; is certainly likely to be banned in Nixpkgs at some point I think | 16:29:57 |
| emily | since people have already put work into treewides/warnings for it | 16:30:06 |
 K900 | It doesn't have to be passed in as sha256 = | 16:30:09 |
| K900 | hash = "sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" works | 16:30:30 |
| K900 | (is this stupid? yes. are we stuck with it? also yes) | 16:30:35 |
| emily | sha256:… is worse IMO, since that is just a pretty arbitrary non-standard format | 16:30:36 |
| emily | AIUI on the Nix end at least it's explicitly considered legacy/compat | 16:30:43 |
| K900 | Yes but it's a format we already have that doesn't require exposing weird API surface for the problem that convertHash is used to actually solve | 16:31:09 |
| emily | as in if I had to choose between proliferating sha256 = …; and hash = "sha256:" + …; I'd pick the former | 16:31:23 |
| K900 | And if we ever end up in a world where only SRI is accepted, I'd rather have a builtins.legacyHashToSRI or whatever | 16:31:41 |
| emily | I mean… a built-in that thinks about hash formats is exactly what Raito is so opposed to AIUI | 16:32:09 |
| emily | I would just implement convertHash because it doesn't seem that bad to me :) | 16:32:18 |
 WeetHet | Does nixpkgs need convertHash? | 16:33:25 |
| emily | maybe hash = { algo = "sha256"; format = "nix32"; digest = …; } would be nice. | 16:33:32 |
| WeetHet | Out of tree people can just use IFD | 16:33:36 |
| K900 | Actually that would be very nice | 16:33:47 |
| K900 | I think | 16:33:50 |
| emily | see https://github.com/NixOS/nixpkgs/pull/451929 | 16:33:59 |
| K900 | That's almost a good abstraction | 16:34:03 |
| WeetHet | Isn't nixpkgs minimum nix version still 2.18? | 16:36:56 |
| emily | but if the implementation is going to consume those structured formats, then there's an argument for a built-in to convert them :) | 16:37:15 |
| 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 |
