| 5 Jun 2021 |
 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 |
| cdepillabout | Yeah, I think their documentation calls it materializing. If you wanted to move haskell.nix into nixpkgs, you'd have to generate (materialize?) all the .nix files and check them into nixpkgs. | 13:34:04 |
| cdepillabout | Ah, maybe we're talking about different things. I'm trying to say that it would be possible in theory to use haskell.nix to provide a Haskell package set similar to the one that Nixpkgs provides. | 13:34:34 |
