| 14 Oct 2025 |
 emily | well, we are here because convertHash is not desired and I said the main way I can imagine decomposing it is to split out SRI/<hash>:<algo> parsing, and to split conversion/deconversion using NUL bytes in strings | 16:28:38 |
 K900 | Like all the uses of convertHash I'm seeing right now are "convert to SRI and shove it in a FOD" | 16:29:17 |
| *  raitobezarius is not going to debate the need of convertHash or not for end user code | 16:28:59 |
| emily | I'm ambivalent. I'm not really trying to push for it. I'm just noting that it's something that comes up fairly often and that we've had Nixpkgs hash divergence from attempts at feature detecting it | 16:29:18 |
| emily | the demand is not from me, but there is demand :) | 16:29:23 |
| K900 | Which is objectively useless | 16:29:37 |
| K900 | And could just be "sha256:" + hash | 16:29:43 |
| 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 |
