| 14 Oct 2025 |
 emily | this may be more "pure" but it also feels a bit error-prone compared to just having convertHash handle it | 16:10:43 |
| emily | but it at least only needs solving once | 16:10:52 |
| emily | (unless the quirks change later) | 16:10:55 |
 raitobezarius (DECT: 7248) | Yeah, but that direction is easy because the implementations accepts more than they should | 16:10:57 |
| raitobezarius (DECT: 7248) | which would be a regression caught by tests hopefully | 16:11:30 |
| emily | I think you would need a size parameter | 16:11:35 |
| 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 (DECT: 7248) | 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 (DECT: 7248) | I don't know what is the timeline you are operating with to have this code available | 16:13:39 |
| raitobezarius (DECT: 7248) | 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 |
