| 14 Oct 2025 |
 emily | which is not very nice | 16:11:39 |
| emily | because now Nixpkgs has a look-up table of hashes to byte sizes too… etc. | 16:11:49 |
| emily | not the end of the world | 16:12:02 |
 raitobezarius | I'm pretty confident that we don't want convertHash in Lix, we might accept convertBinary but I'm not super comfy about getting this on a short timeline, I'm confident about {from,to}{NixBase32,Base16,Base64} primitives in builtins.conversions and we can look at an convertHash implementation beforehand with such built-ins on a short timeline | 16:13:05 |
| raitobezarius | I don't know what is the timeline you are operating with to have this code available | 16:13:39 |
| raitobezarius | Seems like the passAsFile thing used there is exploiting an implementation detail about passAsFile internal details, which does not seem to be an excellent usecase for convertHash | 16:14:51 |
 K900 | OK question (please tell me if I'm being stupid), what's the actual use case for this? | 16:16:27 |
| emily | I don't care about it on a personal level, I just know that it regularly comes up as a blocker for using Lix for people, e.g. brew-nix used it, https://github.com/search?q=convertHash+language%3Anix&type=code shows many examples, and as i linked in https://github.com/NixOS/nixpkgs/pull/451929 an attempt to do feature-detection in Nixpkgs caused hash divergence between Nix and Lix | 16:16:35 |
| emily | so I thought it was worth raising again because it seemed to have been bikeshedded into a radix conversion function that wouldn't work to implement the built-in and stalled out | 16:17:07 |
| K900 | Man this is so cursed | 16:17:36 |
| emily | I guess there is no other way to produce an SRI or Base32 hash of a string in Nix currently, e.g. | 16:17:40 |
| K900 | Literally none of those uses of convertHash are valid | 16:17:45 |
| emily | or if you want to convert an SRI hash into a Base16 one for generating a specific lock file format or something | 16:18:19 |
| raitobezarius | I mean I get it if you store your lockfile in a certain format and you want to feed it to Nix FODs | 16:18:27 |
| emily | especially if sha256 etc. are deprecated in favour of hash for fetchers | 16:18:37 |
| K900 | You can just do sha256:<foo> | 16:18:38 |
| raitobezarius | But making this a primitive in builtins is… well… :) | 16:18:41 |
| emily | which people have wanted to do for a while | 16:18:43 |
| K900 | Which is a valid outputHash | 16:18:48 |
| K900 | As in it works everywhere SRI works | 16:18:53 |
| emily | I think there is a desire to standardize on SRI exclusively in Nixpkgs | 16:19:03 |
| K900 | I think this is a non-issue _for generated code- | 16:19:16 |
| K900 | I think this is a non-issue for generated code | 16:19:18 |
| K900 | Or generated drvs | 16:19:21 |
| raitobezarius | From what I see, it's doubly problematic that people have already started doing builtins.convertHash instead of lib.convertHash | 16:19:35 |
| emily | https://github.com/NixOS/nixpkgs/commit/1cf3103bcaf3b45aed2e8e0801f96207d2e98745 seems like a legitimate use case since it is required to match the filename format for passAsFile? | 16:20:24 |
| emily | though admittedly I don't know if there are stability guarantees on that format | 16:20:31 |
| raitobezarius | Of an absolutely undocumented thing | 16:20:34 |
| raitobezarius | Now, we made public and visible the mechanism for .attr- filenames | 16:20:48 |
| emily | right. but it still does not seem that weird to want to compute it | 16:20:59 |
