| 5 Jun 2021 |
 cdepillabout | Yeah, and it still great when people send fixes for them. | 13:06:43 |
 toonn | I think maybe you're talking about the current situation? | 13:06:58 |
| toonn | Back when I used the infra Nixpkgs definitely did not have the latest version of everything. | 13:07:15 |
| toonn | I didn't know Stackage Nightly even used the latest versions of everything? | 13:07:54 |
| toonn | That sounds like you'd be completely giving up the Stackage guarantee? | 13:08:05 |
| toonn | What's even the point of using Stackage then? | 13:08:16 |
 maralorn | I think toonn is right, when it’s about wanting a newer version of a stackage package. But then otoh that would be worse when using stackage. When we are talking about a package outside of stackage. We nearly always have the newest and we only pin it to an older version because of stackage in very rare cases. | 13:08:21 |
| cdepillabout | Huh, maybe that was before my time. As far as I've been using it, Nixpkgs has always had the latest versions of all Haskell packages. Some of them don't work, like you're saying, but we still like getting fixes for them. | 13:08:21 |
| maralorn | cdepillabout: We are not using the latest version for stackage packages. We include it, but we don‘t guarantee it’s building in any way. | 13:09:31 |
| 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 |
