| 5 Jun 2021 |
 cdepillabout | I mean, really you should have been upstreaming stuff. | 13:03:52 |
 sterni (he/him) | part of the pain has been lessened by stackage nightly | 13:04:00 |
| sterni (he/him) | and yeah a big problem is I think ppl having an overlay in their dev environment and not contributing fixes back | 13:04:18 |
| cdepillabout | * I mean, really you should have been upstreaming those jailbreaks and dontChecks. | 13:04:21 |
 toonn | No, I don't think package updates should be upstreamed, especially when, as in my case, they require bumping a ton of deps from the stackage versions. | 13:04:51 |
| toonn | It'd unnecessarily break things for others. That's exactly why depending on Stackage is nice. | 13:05:14 |
| cdepillabout | No, you really should upstream fixes to Nixpkgs. | 13:05:27 |
| cdepillabout | You could at least unbreak the foobar_x_y_z version of the packages. | 13:05:55 |
 maralorn | Well, if it includes manually bumping stackage packages, I am not sure. | 13:05:58 |
| toonn | I think you're not hearing what I'm saying. The "fix" is just needing a newer version. | 13:06:02 |
| toonn | And that newer version needs newer versions of other packages. | 13:06:12 |
| cdepillabout | We have the newest versions of all Haskell packages in Nixpkgs. | 13:06:25 |
| toonn | Which aren't necessarily compatible with the rest of Stackage. | 13:06:26 |
| 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 |
