| 14 Oct 2025 |
 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 |
| raitobezarius | Yeah, but we are mixing up multiple concerns | 16:21:24 |
| raitobezarius | There's the overall desire of doing what the OP of that change is doing | 16:21:32 |
| raitobezarius | And what convertHash should be and how should it serve | 16:21:39 |
| emily | the brew-nix use was admittedly pretty trivial https://github.com/BatteredBunny/brew-nix/commit/88a94a007fc212a04784a3dc0aab6692f405251a | 16:21:44 |
| emily | but I am not sure if hash = "sha256:" + …; is going to be considered desirable long-term once sha256 = …; is deprecated in fetchers | 16:21:58 |
| raitobezarius | To get progress on convertHash, I can free some time to do:
- {from,to}{NixBase32,Base64,Base16} and see what a
convertHash based on that looks like
| 16:21:59 |
| raitobezarius | It's going to be crucial that convertHash exist in nixpkgs | 16:22:10 |
| emily | given it is another quirky non-standard format vs. SRI | 16:22:11 |
