 | Haskell in Nixpkgs/NixOS | 721 Members |
| For discussions and questions about Haskell with Nix, cabal2nix and haskellPackages in nixpkgs | Current Docs: https://haskell4nix.readthedocs.io/ | 145 Servers |
| Haskell in Nixpkgs/NixOS | 721 Members |
| For discussions and questions about Haskell with Nix, cabal2nix and haskellPackages in nixpkgs | Current Docs: https://haskell4nix.readthedocs.io/ | 145 Servers |
| Sender | Message | Time |
|---|---|---|
| 21 Apr 2025 | ||
 @megmug:matrix.org left the room. | 11:25:41 | |
| 22 Apr 2025 | ||
 sterni (he/him) | I'm currently finishing the broken list and am going to merge after that. | 08:52:40 |
| sterni (he/him) | Any further fixes can probably relatively easily be done on staging(-next) | 08:52:56 |
| sterni (he/him) | * I'm currently finishing the broken list and am going to merge after that. Going to take a minute since I manually need to check the queued jobs. | 08:53:20 |
 hellwolf | hurray!
pkgs/development/haskell-modules/configuration-hackage2nix/broken.yaml: "+450-19" Am I reading right that there are 400+ more borken packages because of the 9.8? | 10:15:10 |
| hellwolf | https://github.com/cdepillabout/nix-haskell-updates-status "Top 50 broken packages, sorted by number of reverse dependencies" Is this the place to start to look for the culprits? | 10:17:02 |
 @malteneuss:matrix.org | Manually applying patches and fixing builds for weeks doesn't seem sustainable. If you have the time and haven't done so, please voice your opinion in Discourse on what has to change in GHC and/or Haskell ecosystem upstream to reduce the churn, e.g. https://discourse.haskell.org/t/language-library-and-compiler-stability-moved-from-ghc-9-6-migration-guide/5745/92 (GHC stability/backwards compatibility) https://discourse.haskell.org/t/introducing-the-haskell-foundation-stability-working-group/11743 (GHC stability/backwards compatibility) https://discourse.haskell.org/t/how-much-effort-does-backwards-compatibility-require-from-library-authors/11584 (Haskell ecosystem stability/backwards compatibility) https://discourse.haskell.org/t/request-for-comment-cabal-freeze-doesnt-produce-a-lock-file/11374 (Real Cabal lock files like e.g. Rust) | 11:00:23 |
 maralorn | Yeah, but I wouldn’t worry too much about it. e.g. quite a few of them are likely just packages newly released in the last months others might haven been disabled before because of one broken dep. | 11:00:45 |
| maralorn | malteneuss: Would you want us to use a completely different approach or do you just want to nudge the ecosystem so that we need to apply less patches and fix less builds? | 11:12:37 |
| maralorn | * Yeah, but I wouldn’t worry too much about it. e.g. quite a few of them are likely just packages newly released in the last months others might haven been disabled before because of one broken dep which got fixed. | 11:12:45 |
| maralorn | * Yeah, but I wouldn’t worry too much about it. e.g. quite a few of them are likely just packages newly released in the last months others might haven been disabled before because of one broken dep which got fixed. Yet, some others are newly broken, but if they are unmaintained probably no one cares. | 11:13:21 |
| @malteneuss:matrix.org | My gut feeling is that we need both. | 11:13:35 |
| maralorn | My gut feeling is that we are actually delivering an astonishingly large amount of working packages compared to the amount of work we are investing. While we can certainly decrease the friction by removing some small or big paper cuts, I can’t think of a different approach which could improve on that. | 11:16:19 |
| maralorn | Especially anything related to lockfiles is not likely going to help. | 11:16:54 |
| maralorn | What would help would be a) a cultural strengthening that everyone maintains there packages in stackage and b) ecosystem wide sharing of overrides and patches. | 11:17:47 |
 alexfmpe | I still think what nixpkgs does is what stackage should be | 11:22:35 |
| alexfmpe | It's insane to me they don't run test suites | 11:22:56 |
| alexfmpe | Nor ever patch things | 11:23:07 |
| alexfmpe | I don't want to bump my deps if the DB roundtrip tests fail or some encryption library tests fail | 11:24:20 |
| maralorn | I had a cool discussion on zurihac about the fact that there io the concept of hackage overlays. E.g. head.hackage. and it would be awesome if we could maintain our overrides as a hackage overlay which we could import into nixpkgs but als share and maintain together with the rest of the community. | 11:24:24 |
| alexfmpe | Yeah I agree. I don't see the point of there being stackage overlay, nixpkgs overlay, horizon overlay plus iog and obsidian nix jungles | 11:25:44 |
| alexfmpe | We're all tackling the same problem | 11:25:53 |
| alexfmpe | Well stackage isn't an overlay per se | 11:26:34 |
| maralorn | Problem is that it is kinda fishy to maintain a community wide patchset which is overriding the package authors. That has a very complicated trust model. | 11:27:45 |
| alexfmpe | In reply to @alexfmpe:matrix.orgBut it's not an orthogonal layer we can just be agnostic to. If they have some package deep in the dependency chains that is broke but only the tests expose it, stackage will happily base other package versions around it and then we need to undo a part of that | 11:28:47 |
| alexfmpe | In reply to @maralorn:maralorn.deThat's true but | 11:29:32 |
| alexfmpe | How does anyone but the package authors prevent the need of after the fact fixups? | 11:30:50 |
| alexfmpe | What I think we can do is be more strict on the whole *nudge upstream when adding overrides* | 11:31:37 |
| alexfmpe | In reply to @alexfmpe:matrix.orgFor instance, both js and wasm backends are unusable without overrides if they depend on splitmix | 11:32:38 |
| maralorn | In reply to @alexfmpe:matrix.orgMaybe we can automate this better and do it earlier. | 11:32:51 |