| 5 Jun 2021 |
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 |
sterni (he/him) | so it doesn't exist | 13:44:13 |
| ic.rbow joined the room. | 13:46:19 |
sterni (he/him) | I really hate that apparently everything I want to do to hackagen2ix means touching distribution-nixpkgs nowadays | 14:20:31 |
sterni (he/him) | in other news: https://github.com/peti/distribution-nixpkgs/pull/11 | 14:20:34 |
sterni (he/him) | (also need to fix CI) | 14:20:40 |
maralorn | sterni (he/him): Can you remind me again why this use of with could be harmful? | 14:22:03 |
maralorn | * sterni (he/him): Can you remind me again why this use of with could be harmful? | 14:22:21 |
maralorn | It will break when I finally upload my sternenseemann library to hackage? | 14:22:59 |
sterni (he/him) | exactly | 14:23:05 |
sterni (he/him) | it's not urgent but nice to have fixed tbh | 14:23:25 |
sterni (he/him) |
| 14:24:27 |
sterni (he/him) | * nix-repl> lib.intersectLists (builtins.attrNames lib.maintainers) (builtins.attrNames haskellPackages)
[ "astro" "buffet" "cap" "cpu" "disassembler" "rob" "yarr" ]
| 14:24:33 |
maralorn | Have you considered replacing [ lib.maintainers.a lib.maintainers.b ] with builtins.attrValues { inherit (lib.maintainers) a b; }? | 14:24:40 |
sterni (he/him) | there's your motivation :) | 14:24:41 |
maralorn | I now cap, I doubt they will ever maintain a Haskell package.^^ | 14:25:15 |
sterni (he/him) | In reply to @maralorn:maralorn.de Have you considered replacing [ lib.maintainers.a lib.maintainers.b ] with builtins.attrValues { inherit (lib.maintainers) a b; }? more hassle to implement plus extra evaluation cause which is not negliable I think | 14:25:16 |
maralorn | In reply to @sternenseemann:systemli.org more hassle to implement plus extra evaluation cause which is not negliable I think We can increase the hassle by only doing it, when it’s more than one maintainer. | 14:26:02 |
maralorn | I think that way it would be pretty cheap too. | 14:26:17 |