| 23 Apr 2026 |
 Alex | I know for certain that build-tools can be made to work, but not specifically build-tool-depends.
Do any of these examples answer your question? | 22:05:46 |
 eldritchcookie | the one package +preprocessing seems to use build-tool-depends how i want to use it | 22:27:42 |
| eldritchcookie | i can't compile and i get a error similar to the one on my own project, so it is something with my ghc/cabal-install version? | 22:36:55 |
| eldritchcookie | which version of cabal was used to compile this project? | 22:37:24 |
| eldritchcookie | wait this is intended to be compiled only via nix? | 22:39:02 |
 m1-s | Not sure if this is the right place but I am looking for feedback for this cabal2nix PR: https://github.com/NixOS/cabal2nix/pull/717 | 22:39:58 |
| 24 Apr 2026 |
 alexfmpe | it is the right place, though I think maintainer(s) of cabal2nix are currently swamped | 10:23:52 |
| alexfmpe | m1-s: I don't understand what you're going for though | 10:24:13 |
| alexfmpe | you can build packages with multiple libraries just fine, here's an example with a ton of them: https://hackage-content.haskell.org/package/raaz-0.3.11/src/raaz.cabal | 10:25:57 |
| alexfmpe | what you can't currently do, is differentiate between multiple components of the same type | 10:26:16 |
| alexfmpe | seems to me your PR differentiates between main-lib and other-libs, not between all libs | 10:26:42 |
| alexfmpe | somewhat related, ICYMI
https://github.com/NixOS/cabal2nix/pull/709
https://github.com/NixOS/cabal2nix/pull/716 | 10:27:09 |
| alexfmpe | well haskell.nix does allow this, but nixpkgs doesn't yet | 10:28:19 |
| alexfmpe | oh I misread, I see your subLibraryDepends is actually a map | 10:29:18 |
| 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 |
