| 29 Jan 2025 |
 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 |
| alexfmpe | At any rate, I'd expect 2 months or so for obeliskverse to be on at least 9.10 and post-ghcjs world | 15:55:40 |
 hellwolf | I wonder, with the current haskell-updates, what chances I have to jailBreak haskell.packages.ghc910.hlint_3_8 ... | 19:04:19 |
| maralorn | As always I have to ask: Why built hlint with ghc910? hlint will work perfectly fine when compiled with older ghcs. If you need support for new syntax the relevant version is that of ghc-lib-parser. | 20:31:58 |
 sterni (he/him) | maralorn: could be interesting how far you can get with this, but I suspect it's difficult. It is certainly not intended and I assume you need to build all libs for ghc or some program that is shipped with ghc | 20:35:25 |
| sterni (he/him) | you'll probably get inconsistent dependencies as soon as you link against ghc | 20:37:09 |
| maralorn | But only in previous stages, right? | 20:42:49 |
