| 6 Nov 2024 |
 Manuel Bärenz | One reason for really having a devShell with haskell package dependencies and somehow push through all the trouble with overrides would be to give collaborators a smoother developing experience because we can use a joint cache | 11:00:11 |
 chreekat | Yeah I totally get that and I wish there was a better way | 11:04:56 |
| Manuel Bärenz | And I still wonder. We're building packages on nixpkgs for 9.10 even when there is no Stackage LTS with that GHC, right? So those packages just mostly don't work? We only start fixing packages when we bump the main GHC version to that of the latest LTS, right? Would it be possible to start fixing for the latest GHC, even if we're ahead of Stackage? Or would it be much more work because we can't benefit from all the fixes that Stackage contains when they start an LTS? | 11:07:15 |
 maralorn | Well, we actually only build very little packages for 9.10. That being said we regularly have contributions to fix packages on newer GHCs and that is very appreciated. We do it especially so that it is possible to provide working devshells. i.e. we aim to have hls working, which is one of the few dev-tools which need to be compiled with the dev-ghc. | 12:09:52 |
| maralorn | If you are comfortable with doing the overrides and you want that to be available for all devs then please do so. (und upstreaming those would be great). But it is a hazzle for which we have no workaround, so especially for people which are not comfortable with doing it, I recommend to just skip it. | 12:12:30 |
| maralorn | In reply to @maralorn:maralorn.de
Well, we actually only build very little packages for 9.10. That being said we regularly have contributions to fix packages on newer GHCs and that is very appreciated. We do it especially so that it is possible to provide working devshells. i.e. we aim to have hls working, which is one of the few dev-tools which need to be compiled with the dev-ghc. But yes because it is more work to do it ahead of HLS the current quality bar of the core maintainers is to get build tools running on newer ghcs. Everything else is welcome but we don’t work on that, because it doesn’t seem like a worthy priority. | 12:14:46 |
| maralorn | In reply to @maralorn:maralorn.de
Well, we actually only build very little packages for 9.10. That being said we regularly have contributions to fix packages on newer GHCs and that is very appreciated. We do it especially so that it is possible to provide working devshells. i.e. we aim to have hls working, which is one of the few dev-tools which need to be compiled with the dev-ghc. * But yes because it is more work to do it ahead of LTS the current quality bar of the core maintainers is to get build tools running on newer ghcs. Everything else is welcome but we don’t work on that, because it doesn’t seem like a worthy priority. | 12:15:05 |
| Manuel Bärenz | Thanks for the explanations! | 13:30:20 |
| maralorn | I feel like probably the biggest image problem that our package set has is that the design looks to outsiders like it has different goals and quality goals than we actually have. | 14:46:29 |
| maralorn | Generating 16k of which 2/3 are broken just looks bad. Without explanation no one comes up with the tradeoff that it is just more convenient for us (and them) to leave the broken derivations in instead of deleting them. | 14:48:08 |
| maralorn | Similar problems with the different ghc version package sets. | 14:48:27 |
| maralorn | Although I think it is a glaring hole, that search.nixos.org does not display broken flags. | 14:48:55 |
| maralorn | * Although I think it is a glaring hole that search.nixos.org does not display broken flags. | 14:49:01 |
 lxsameer | maralorn: sterni hey folks, here is the repo for the simplest possible implementation of what we've talked about so far. could you please have a look when you have free time to spare? Please bear in mind that I'm not a haskell developer, so any feedback even the smallest would be appreciated https://git.sr.ht/~lxsameer/cabalfreeze2nix | 16:00:49 |
| lxsameer | i think we can do things in iteration. we don't have to go all in at once | 16:01:49 |
| maralorn | lxsameer: This is awesome, even before looking at it. I will put it high on my todolist, but I have a bit of vacation planned for the next few days so it might take a moment. | 16:08:10 |
| lxsameer | In reply to @maralorn:maralorn.de
lxsameer: This is awesome, even before looking at it. I will put it high on my todolist, but I have a bit of vacation planned for the next few days so it might take a moment. no worries at all and hope you enjoy your holiday ;) | 16:08:48 |
| 8 Nov 2024 |
|  jschvz joined the room. | 02:56:07 |
|  moved to @amadaluzia:tchncs.de changed their display name from (artur 'manuel) to @amadaluzia:tchncs.de. | 14:28:41 |
| moved to @amadaluzia:tchncs.de changed their display name from @amadaluzia:tchncs.de to moved to @amadaluzia:tchncs.de. | 14:29:55 |
 thirdofmay18081814goya | anyone got a minimal haskell project flake I can grab? | 15:15:35 |
| thirdofmay18081814goya | (or non-minimal works too) | 15:15:44 |
| lxsameer | https://git.sr.ht/~lxsameer/cabalfreeze2nix/tree/master/item/flake.nix | 15:16:06 |
| lxsameer | https://git.sr.ht/~lxsameer/nixit/tree/master/item/modules/haskell/default.nix | 15:16:25 |
| thirdofmay18081814goya | nice ty!! | 15:17:22 |
 sterni (he/him) | lxsameer: I think the next step is probably generating the actual package expressions as well in line using cabal2nix. Relying on the IFD helpers is going to hamper performance and if you have to generate code anyways… | 17:25:14 |
| sterni (he/him) | of course, the question is a little bit how to ensure that cabalfreez2nix itself can be used in ifd | 17:25:38 |
| lxsameer | In reply to @sternenseemann:systemli.org
of course, the question is a little bit how to ensure that cabalfreez2nix itself can be used in ifd IFD? | 17:50:48 |
| lxsameer | btw thanks for the patch set | 17:52:55 |
 @selkie-diligent-61ad45186da03739848be880:gitter.im | lxsameer: IFD is https://nix.dev/manual/nix/2.24/language/import-from-derivation | 18:08:12 |
