| 25 Feb 2026 |
 chreekat | HF pays :3 | 18:16:49 |
 maralorn | Probably still not as good as the other client. 😆 | 18:21:56 |
|  Void Ember changed their display name from Void Mona(d) to Void Ember. | 19:11:27 |
| 26 Feb 2026 |
| chreekat | sterni: https://github.com/commercialhaskell/all-cabal-hashes/commit/e89f69681f6366e77ab017b8b496c4ee2c6825b5 | 10:19:40 |
 sterni | great thank you! did not get my change cleaned up in time… | 11:44:39 |
| chreekat | You should use casa! It also needs an update, but it's the superior, undocumented choice to all-cabal-hashes imo | 12:37:51 |
| chreekat | I'm gonna get it (casa.stackage.org) up to speed next | 12:38:33 |
| sterni | is it documented anywhere? | 13:42:26 |
| sterni | but I do not think we actually need it, the hackage index has everything we need nowadays as long as the index state timestamp is reliable but should be ok | 13:43:03 |
| chreekat | Just a couple old blog posts | 13:44:51 |
| chreekat | Interesting. I did not know you could just go straight to hackage now. I know that casa solved problems when it was developed, the same problems all-cabal-hashes was supposed to solve | 13:50:12 |
 teo (they/he) | I think the issue that all-cabal-hashes solves (for nix) is that you want to map a package name and revision to a cabal file hash at nix eval time, which I don't think you can do with casa without IFD | 14:29:34 |
| chreekat | True, you probably need dynamic drvs in order to follow the chain from a fod that pulls the top of the tree to all the other fods that describe the package source | 15:25:26 |
| maralorn | Dynamic drvs are not allowed on hydra, are they? | 15:27:14 |
| chreekat | I assume not, but at least it's theoretically more pleasing than ifd | 15:36:57 |
| chreekat | So, I will carry on dreaming 😄 | 15:37:30 |
 toonn | Recursive Nix was another such dream. | 16:00:06 |
| maralorn | Isn’t even basically the same? | 16:10:26 |
| toonn | Both of them and IFD basically achieve the same thing AFAIK. | 16:12:31 |
| toonn | Different trade-offs to reach at least similar goals. | 16:12:49 |
| sterni | we can't even do that since the database is not available at eval time (it's a derivation after all) | 16:13:04 |
| sterni | but yes, we need to figure out the latest package version and revision for a package with the sha256 hash of the cabal file (in case it is revised) and the sdist when generating hackage-packages.nix | 16:14:24 |
| sterni | I don't know if historically something was missing from the cabal-install database or restricting it to a specific state was too complicated, but it seems like we can get all the information we need from the index now. | 16:16:10 |
| sterni | with the slight downside that it needs to be managed on the developer's machine by cabal-install since there's no way to fetch a specific version of the index | 16:16:43 |
| sterni | I think we are going to need all-cabal-hashes going forward for callHackage anyway, a nicer alternative there would be useful | 16:17:05 |
| teo (they/he) | Yeah good point!
Tbh maybe we could just require people put the hash into the callHackage call and then not have to do any of this? | 16:19:23 |
| sterni | yeah that already exists | 16:41:17 |
| sterni | i think retaining that feature is not that interesting since the snapshot you’re getting is always outdated by a week at least | 16:42:11 |
| maralorn | idk, sometimes you want a newer version of something which is pinned in stackage but the newest _version doesn’t cut it. | 17:00:45 |
| maralorn | I use the hash based pinning quite regularly. | 17:00:58 |
