| 28 Nov 2024 |
 alexfmpe | The lib | 20:02:48 |
| alexfmpe | assuming it's something like
w_5 <> h_5 <> md w_10 | 20:03:46 |
| alexfmpe | * assuming it's something like
w_5 <> h_5 <> md w_10
or
w 5 <> h 5 <> md w 10 | 20:04:07 |
 maralorn | That doesn’t seem unrealistic, does it? | 20:06:17 |
| alexfmpe | It starts getting weird with w-3/4 or w-auto | 20:06:31 |
| alexfmpe | Clay does a gazillion classes to get all this overloading | 20:06:43 |
| alexfmpe | In reply to @maralorn:maralorn.de
That doesn’t seem unrealistic, does it? I mean I'm sure it's doable | 20:06:55 |
| alexfmpe | but, in reflex-dom case, it's pretty hard to beat
divClass "w-3/4 p-4" | 20:07:50 |
| alexfmpe | divTw (w (3/4) <> p 4) | 20:08:28 |
| alexfmpe | Looks much worse | 20:08:35 |
| alexfmpe | or
divTw [w (3/4, p 4] | 20:10:12 |
| alexfmpe | And you basically need implicit params on the argument of divTw | 20:10:44 |
| alexfmpe | Or it will be much worse | 20:10:54 |
| alexfmpe | divTw [T.w (3/4), T.p 4] | 20:11:18 |
| alexfmpe | if one could have a TH pass or whatever typecheck the string literals, that'd be interesting | 20:12:51 |
|  @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 |
