| 5 Jun 2021 |
 cdepillabout | toonn: Ah, maybe we're talking past each other. So Nixpkgs often has two versions of each Haskell package. It has something like foobar pinned to the version of the foobar package in Stackage, and then foobar_1_2_3_4 for the latest version of the foobar package on Hackage (assuming it is version 1.2.3.4). | 13:09:47 |
 maralorn | Again if you often need a newer ghc or a package newer than in stackage I agree that haskell.nix would probably be less pain. | 13:11:01 |
| cdepillabout | maralorn: Yeah, but it is still great to get fixes for those packages though, specifically because we don't really guarantee they are working. | 13:11:28 |
| maralorn | Granted. I just have the feeling that at this point so few people are doing that, that going down this road means probably a lot of work. | 13:12:24 |
| maralorn | I‘d still do it that way. But I understand that people don‘t always want to become nixpkgs maintainers.^^ | 13:12:57 |
| cdepillabout | Yeah, that's a good point. I guess it depends on how far your dependencies are from stackage. Although I think you have a good point with haskell.nix. If you're happy with cabal's solver or stackage snapshots, it is a good choice. | 13:13:57 |
| maralorn | otoh you recompile a lot when you do that … | 13:14:22 |
 toonn | Yes, but at least it's incremental with cabal and stack too probably. | 13:15:09 |
| maralorn | Still on the other at least from my vantage point crazy cool super shiny major improvements to stackage packages which don‘t quickly get into stackage are not that often. | 13:15:26 |
| cdepillabout | Ah, yeah, I wouldn't want to use haskell.nix unless I also used their cache. | 13:16:37 |
| maralorn | If you rely on cabal build plans I feel like you can quickly get cache misses. | 13:17:05 |
| maralorn | Still on the other hand, traditional cabal users always recompile all their deps and that’s not a big issue … | 13:17:35 |
| cdepillabout | Yeah, I could definitely see that happening. At least you hopefully won't have to build GHC though | 13:17:49 |
| toonn | Even if you use their cache it's not hard to step off the cliff. | 13:18:07 |
| maralorn | I actually think haskell.nix and cabal2nix have both their strong suits and I don‘t think that there are any philosophical reasons that all of the features could exist in one tool. | 13:19:24 |
| toonn | I've been rebuilding stdenv quite a bit lately. That has mellowed my view on rebuilding GHC a *lot*. Highly recommended if that's something that bothers you : ) >.< | 13:19:25 |
| maralorn | I think providing a way to build a package from a cabal build plan is something that nixpkgs could support. | 13:20:08 |
| maralorn | Of course haskell.nix is backed by a big company. It’s hard for us volunteers to reach feature parity with that. I wish there would have been a way that they could have applied their efforts so that the community can profit even more. | 13:22:11 |
| cdepillabout | Yeah, I've thought about that as well. I wonder if there is some way we could somehow merge our Haskell stuff with the haskell.nix infrastructure. I can only imagine it would be a huge amount of work though. | 13:23:40 |
| toonn | Afaict they weren't averse to that. But the Nixpkgs policy on IFD prevents it. | 13:24:14 |
| cdepillabout | Yeah, I imagine they'd have to generate a package set and check it in to Nixpkgs, similarly to how Nixpkgs currently does it. | 13:29:11 |
| toonn | But then you lose the advantage of haskell.nix? | 13:29:36 |
| toonn | Because the flexibility is the advantage. | 13:29:43 |
| cdepillabout | I mean, I can totally understand that they just wanted to iterate quickly on their own toolkit rather than trying to get it upstreamed into nixpkgs. | 13:29:52 |
| cdepillabout | I don't think the primary advantage of haskell.nix is IFD. I think it is that you can generate a Haskell package set from the cabal solver or an arbitrary stackage package set. | 13:30:45 |
| toonn | IFD is not an advantage. It's how it works its magic. | 13:31:11 |
| cdepillabout | No, you could easily use haskell.nix without relying on IFD. They have all the tooling setup to make it possible. | 13:31:36 |
| toonn | The flexibility in package versions which is the result is the advantage. | 13:31:40 |
| toonn | Are you talking about pinning? | 13:32:04 |
| toonn | Uh, materializing. | 13:32:14 |
