| 24 Apr 2026 |
 alexfmpe | then I'm confused in a different way, why only do this for libraries? | 10:32:10 |
 m1-s | mhm maybe I misunderstood the current capabilities. I will do some more research. Thanks for your feedback! | 11:23:04 |
| alexfmpe | I mean, the only thing special about library components is that you can have a main library. So I'd expect what you're doing to be applicable to executables/benchmarks/tests | 12:32:12 |
| alexfmpe | I think most of the work is on the nixpkgs side though. We have hundreds of overrides and I'd bet over 100 of them directly rely on current structure, and the rest use dozens of utils that also do | 12:34:29 |
| alexfmpe | So we'll need to make those utils recover current behavior with new structure, then add a migration path for component-granularity override | 12:35:24 |
| alexfmpe | * So we'll need to make those utils recover current behavior with new structure, then add a migration path for component-granularity overrides | 12:35:31 |
| alexfmpe | Maybe the way to go is actually first doing this end to end just for internal libraries which are less common, then gradually rollout to benchmarks, executables, test suites | 12:36:46 |
 aiya | how long does it usually take for a new version from hackage to make it into haskell-updates? assume the package isn't on stackage | 18:59:20 |
| 25 Apr 2026 |
|  @axeman:pub.solar left the room. | 09:04:52 |
 eldritchcookie | I would assume the package gets into haskell-updates in the next time they regenerate hackage-packages.nix. The HACKING.md says that each member is responsible for updating the packages for a 2 week period, i assume they must always do something in that period so they probably run the scripts at least once.
Assuming they always run the scripts mentioned under the second header the scripts are ran at least once per 2 weeks, further assuming no unexpected we can expect it to take at most 2 weeks for an update. these are just assumptions based on the current documentation please have a backup plan in case it takes longer.
Also why is that relevant? can you apply an overlay to the package set you use? if yes i wouldn't wait and just use callHackageDirect via the self argument of the overlay | 14:50:30 |
| eldritchcookie | # callHackageDirect
# :: { pkg :: Text, ver :: Text, sha256 :: Text }
# -> AttrSet
# -> HaskellPackage
#
# This function does not depend on all-cabal-hashes and therefore will work
# for any version that has been released on hackage as opposed to only
# versions released before whatever version of all-cabal-hashes you happen
# to be currently using.
callHackageDirect =
{
pkg,
ver,
sha256,
candidate ? false,
rev ? {
revision = null;
sha256 = null;
},
}:
args:
<body>
| 14:55:49 |
| alexfmpe | pretty much this, though the 2 weeks is more of a rough estimate for maintainer rotation of that duty | 15:25:11 |
| alexfmpe | most of the time we bump hackage alonside a minor stackage bump | 15:25:47 |
| alexfmpe | "Current PR:" in the channel description will show the state of current bump, so you can guesstimate (2 weeks - age) for the next | 15:26:29 |
| alexfmpe | in pratice it varies wildly depending on breakage, some have taken days, some have taken several weeks | 15:26:47 |
| alexfmpe | and major stackage bumps can take months until merged | 15:27:05 |
