| 5 Jun 2021 |
 Las | It's this commit: https://github.com/NixOS/nixpkgs/commit/7191381b24b511017207205e2c8625a91ccea5cf | 20:03:21 |
 maralorn | Las: Hm, okay. sterni (he/him) the problem is: We don‘t have a ghc9 cabal2nix job. So we have nothing with a distribution-nixpkgs dependency. | 20:07:52 |
| maralorn | I guess we could/should introduce that job anyways? | 20:09:34 |
| maralorn | We could actually consider building either mergeable or even maintained for ghc9 … | 20:10:07 |
| maralorn | I think it’s a bit ridiculous that not even hoogle builds on ghc 9 … | 20:11:11 |
 Roos | I find very disturbing there's so much breakage when the compiler updates... | 20:18:59 |
| Roos | * I find very disturbing for the language there's so much breakage when the compiler updates... | 20:18:59 |
| * Roos goes to check GHC9 release notes. | 20:19:00 |
| maralorn | Roos: There actually isn‘t much breakage. It’s mostly that a) everyone needs to bump their base upper bound and b) things that link against ghc have a hard time. | 20:39:08 |
| Roos | That's reassuring ^^" | 20:40:13 |
 fgaz | regarding the discussion from earlier today: I think the haskell binary cache from nixpkgs is mostly useful for experiments or short-term stuff. Once you start working on long-lived project, the warm-up time for the cabal cache gets negligible, and you gain the advantage of being able to work with any version of a package | 21:07:07 |
| fgaz | (of course the haskell stuff in nixpkgs is still very useful for packaging though) | 21:07:28 |
| fgaz | In fact, I almost stopped using nixpkgs for haskell development. Still, nix remains useful for caching this environment for ci, deployments, and sharing it with other developers. And that's why I'm working on my own builder based on cabal and FODs | 21:11:31 |
| fgaz | * regarding the discussion from earlier today: I think the haskell binary cache from nixpkgs is mostly useful for experiments or short-term stuff. Once you start working on long-lived project, the warm-up time for the cabal cache gets negligible, and by avoiding nixpkgs you gain the advantage of being able to work with any version of a package | 21:12:18 |
| fgaz | * regarding the discussion from earlier today: I think the haskell binary cache from nixpkgs is mostly useful for experiments or short-term stuff. Once you start working on long-lived projects, the warm-up time for the cabal cache gets negligible, and by avoiding nixpkgs you gain the advantage of being able to work with any version of a package | 21:14:48 |
| maralorn | FOD? | 21:16:17 |
| fgaz | Fixed-output derivation | 21:16:57 |
| maralorn | Ah | 21:17:06 |
| Las | what would you use fixed-output derivations for? | 21:17:34 |
| fgaz | For the deps' sources | 21:17:55 |
 ahdyt | In reply to @fgaz:matrix.org
In fact, I almost stopped using nixpkgs for haskell development. Still, nix remains useful for caching this environment for ci, deployments, and sharing it with other developers. And that's why I'm working on my own builder based on cabal and FODs You don't use stack? | 21:18:38 |
| ahdyt | * You didn't use stack? | 21:19:11 |
| fgaz | In reply to @fgaz:matrix.org
For the deps' sources This way, I avoid both IFD, and a centralized and somewhat difficult to maintain index like haskell.nix's | 21:19:37 |
| fgaz | In reply to @ahdyt:matrix.org
You didn't use stack? Nope, it's a cabal-specific builder. It's simpler for me this way | 21:19:59 |
| maralorn | In reply to @fgaz:matrix.org
For the deps' sources You mean you do something like the cargoVendorHash rust does? | 21:32:28 |
| fgaz | basically yes | 21:32:40 |
| fgaz | But this also gets you a dev environment (though it's monolithic) | 21:34:39 |
 sterni (he/him) | current plan is to merge haskell-updates sometime tomorrow | 23:32:31 |
| sterni (he/him) | the regressions that are left look unconcerning and the next things I want to do are set rebuilds, so… | 23:32:36 |
| 6 Jun 2021 |
 cdepillabout | Nice, looks like 8.10.5 was released: https://discourse.haskell.org/t/announce-ghc-8-10-5-released/2615 | 02:47:22 |
