| 5 Jun 2021 |
 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 |
 maralorn | Well I think currently haskell.nix and nixpkgs use different ghcs. that makes them super incompatible. I think the desirable goal of unification would be, that users could use nixpkgs to build their packages with a cabal build plan which reuses all derivations which match that are currently in nixpkgs. | 13:41:58 |
| maralorn | I am not even convinced that it would be very hard to do that with cabal2nix. | 13:43:34 |
| toonn | You can use whatever GHC with haskell.nix (within limits). I assume Nixpkgs would build their own. | 13:43:42 |
| sterni (he/him) | toonn: that pr is only in nixUnstable, is it? | 13:43:52 |
| maralorn | sterni (he/him): Surely | 13:44:00 |
| toonn | Yeah. | 13:44:02 |
| sterni (he/him) | ah yeah | 13:44:07 |
