| 29 Jan 2025 |
 Manuel Bärenz | Which is particularly confusing because I'm trying to build for GHC 9.4 | 13:59:22 |
 alexfmpe | default HLS is built with 9.6 no? | 14:39:15 |
| alexfmpe | or maybe in this case it's cabal2nix | 14:39:46 |
| Manuel Bärenz | Yes, but I'm taking care to use HLS from the same GHC that I want to build with. I'll double check whether I've messed that up | 14:40:14 |
 maralorn | Well, the chain is this: | 14:40:25 |
| maralorn | You are using cabal2nix, which is taken from the 9.6 package set. | 14:40:52 |
| maralorn | Und your override for mtl invalidates the hadrian for 9.6. | 14:41:33 |
| Manuel Bärenz | But if I do hprev.callCabal2nix (where hprev is the second argument in my haskell packageOverrides), shouldn't that fix it? I've tried that and it doesn't | 14:45:09 |
| maralorn | I have no clue from where callCabal2nix picks its cabal2nix. | 14:45:58 |
| Manuel Bärenz | Yeah, the fixpoint might not be tight | 14:46:19 |
| maralorn | Yep | 14:47:43 |
| maralorn | It uses pkgs.cabal2nix-unwrapped | 14:47:55 |
| Manuel Bärenz | I tried to replace callCabal2nix with a completely vanilla one, no change | 14:48:00 |
| maralorn | Or is that haskellPackages.cabal2nix-unwrapped? | 14:48:26 |
| Manuel Bärenz | Maybe it's my shellFor...? But for that I need the overridden package set | 14:48:28 |
| maralorn | * ~~Or is that haskellPackages.cabal2nix-unwrapped?~~ | 14:48:48 |
| maralorn | Are you applying your haskellPackages override to a nixpkgs? | 14:49:12 |
| Manuel Bärenz | Yes | 14:49:21 |
| maralorn | Well then this makes sense. | 14:49:30 |
| maralorn | pkgs.cabal2nix-unwrapped references pkgs.haskellPackages. So if you override pkgs.haskellPackages that will affect cabal2nix. | 14:50:03 |
| Manuel Bärenz | I tried not doing that, but then my package didn't appear at all in the package set | 14:50:06 |
| maralorn | Not sure what you mean by that. | 14:50:28 |
| maralorn | sterni: Do you think it could be possible for us to handle bootpackages differently? i.e. could we maybe not compile most of the bootpackages in the ghc derivation or compile them but delete them from the ghc-pkg db and instead not null them in our configuration-*.nix files? | 15:38:16 |
| maralorn | Of course that won’t work for template-haskell, base, ghc-prim and a few more. | 15:40:28 |
 lazyLambda | only thing that came up there was from beam-core | 15:47:21 |
| lazyLambda | I did do an override of beam-core in my projects default.nix but I was more so confused on why the module Rhyolite.Account had a beam type.
| 15:48:35 |
| lazyLambda | Was able to resolve btw | 15:48:48 |
| alexfmpe | FWIW, I'm already using 9.6 and multi repl for dev with a package set directly from nixpkgs (not obelisk->reflex-platform->nixpkgs) instead of ob, and 8.10 only for prod builds | 15:51:25 |
| alexfmpe | Mostly for the sake of a reliable recent HLS | 15:51:51 |
| alexfmpe | You can also get older HLS (with a more brittle multi repl) with enough overrides
https://discourse.haskell.org/t/recommended-way-of-using-hls-with-reflex-platform-obelisk/9933/6 | 15:54:46 |
