| 5 Jun 2021 |
 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 |
| toonn | Yes, I've wondered whether that's something the Haskell infra could move to. | 13:34:41 |
| toonn | But the result still has the disadvantages of the current setup. | 13:35:06 |
| toonn | So it could be an advantage for maintainers but not users? | 13:35:25 |
| cdepillabout | Yeah that is a good point. | 13:35:50 |
| toonn | I'm also not sure how you'd generate the package set tbh. Haskell.nix currently goes by cabal or stack. And neither of those can easily generate a set as big as Nixpkgs includes. | 13:36:35 |
| cdepillabout | Although I'm struggling to imagine how Nixpkgs could provide something as flexible as haskell.nix as long as the restriction on IFD exists. Maybe that is the point you're trying to make? | 13:36:36 |
| toonn | Yes, pretty much. | 13:36:53 |
| cdepillabout | Yeah, haha, that is a good point. | 13:37:14 |
| toonn | Maybe recursive Nix? I'm not sure what the policy on that is but it's been described to me as something that achieves a similar thing. | 13:37:51 |
 sterni (he/him) | recursive nix doesn't exist | 13:39:08 |
| sterni (he/him) | it is something that has been proposed since forever but isn't supported currently | 13:39:24 |
| sterni (he/him) | https://github.com/NixOS/nix/issues/13#issuecomment-328339035 | 13:39:39 |
| sterni (he/him) | * https://github.com/NixOS/nix/issues/13 | 13:39:45 |
| toonn | Have I been bamboozled? https://github.com/NixOS/nix/pull/3205 | 13:39:48 |
| sterni (he/him) | or me :thonking: | 13:40:59 |
