| 28 Nov 2024 |
| @riley:badat.dev left the room. | 20:51:41 |
| 29 Nov 2024 |
| m1-s changed their profile picture. | 02:28:30 |
| m1-s changed their profile picture. | 02:29:51 |
| lassulus changed their profile picture. | 18:30:05 |
Patrick Steele | What's the canonical way to provide an overlay adding a Haskell package to
- A particular version of GHC
- All versions of GHC
In Python, we can pass packageOverrides to python.override; however, this approach doesn't compose nicely, as overlays don't preserve existing packageOverrides unless they explicitly do so. However, there is also the top-level pythonPackagesExtensions, which is a list of overlays to apply that compose naturally.
I can see how to add a Haskell package to the package set by passing overrides to pkgs.haskell.packages.${ghc}.override, but it seems like this would have the same pitfall as the python.override approach. Does Haskell have an equivalent extensions list approach?
| 18:53:03 |
maralorn | .override { overrides = ... } is the recommended way. But I admit I am not sure about the compositionality. | 19:09:41 |
maralorn | I think we also have packageOverrides but it has the same problems. | 19:17:33 |
Patrick Steele | Thanks | 19:54:58 |
| 30 Nov 2024 |
sterni (he/him) | Patrick Steele: overrides defaults to haskell.packageOverrides by default, so changing that attribute applies something globally. Any changes to either of course need to be written in a way that preserve previous overrides via lib.composeExtensions if you care about that. | 11:21:11 |
sterni (he/him) | also note that overriding haskell package set is sort of buggy with a few unresolved issues like https://github.com/NixOS/nixpkgs/issues/235960 | 11:22:52 |
sterni (he/him) | I think some of the fix points used are wrong, I need to look into it at some point | 11:23:16 |
vcunat | sterni: haskell-updates isn't a huge thing, so if you want, I believe it would be OK to be included in this special relatively quick staging-next iteration: https://github.com/NixOS/nixpkgs/pull/360437 | 14:18:55 |
sterni (he/him) | vcunat: that staging-next wasn't branched off from staging right? | 15:28:44 |
sterni (he/him) | The problem is that I merged staging into haskell-updates by accident at some point, so we can't restart the haskell-updates jobset whilst still sharing builds with staging-next. Because the jobset was deactivated for so long, I don't really have a good idea how many regressions there are at the moment. | 15:30:15 |
sterni (he/him) | I suppose we could cherry pick some stuff onto staging-next? | 15:35:11 |
vcunat | If there's something important. Or wait a bit, as it looks like in just a few days there will be a full staging -> staging-next. | 16:26:36 |
vcunat | * Yes, if there's something urgent. Or wait a bit, as it looks like in just a few days there will be a full staging -> staging-next. | 16:26:52 |
vcunat | But you can't really expect that one merging to master sooner than in about two weeks from now. | 16:27:24 |
sterni (he/him) | yeah, that's not ideal, but fine; I don't have a lot of time anyways at the moment | 16:30:29 |
sterni (he/him) | maralorn: anything you want to send to staging quick? | 17:21:54 |
sterni (he/him) | the thing is that a lot of stuff could actually be sent to master as well on haskell-updates 🤔 | 17:22:14 |
vcunat | In reply to @sternenseemann:systemli.org vcunat: that staging-next wasn't branched off from staging right? Correct, it was not. (I forgot this part somehow.) | 17:41:32 |
maralorn | In reply to @sternenseemann:systemli.org maralorn: anything you want to send to staging quick? Nothing comes to mind. | 17:52:12 |
maralorn | We just need to get back into an update rhythm. | 17:52:27 |
vcunat | This won't even rebuild the default ghc if I look right (on x86_64-linux at least). | 17:53:07 |
sterni (he/him) | yeah staging-next looks very tame actually, the stuff that is well tested doesn't cause a lot of rebuilds anyways so we can probably easily pick it: https://github.com/NixOS/nixpkgs/pull/360499 | 17:54:07 |
sterni (he/him) | need to double check the linux rebuild count though that seems wrong | 17:54:16 |
vcunat | I'm doing that already. | 17:54:46 |
vcunat | 11 x86_64-darwin
11 x86_64-linux
| 17:55:05 |
vcunat | That... sounds like it could go to master directly 😆 | 17:55:49 |