| 2 Jun 2021 |
 sterni (he/him) | but may be a lot of annoying manual effort if they don't split the packages, yes | 12:55:35 |
 maralorn | Yeah its quite a hazzle because haskell-gi has so many packages | 13:15:07 |
 Las | Couldn't cabal2nix see what major revision of gi-gtk a package uses and then either use haskellPackages.gi-gtk3 or haskellPackages.gi-gtk4? | 13:25:06 |
| maralorn | Las: Yeah, that would probably not be very hard. But it might require a dive into the code. | 13:27:06 |
| sterni (he/him) | not a fan of inventing virtual packages ourselves though | 13:27:36 |
| Las | You could have a separate package for each major revision of each package to make it orthogonal | 13:29:39 |
| Las | I imagine it's not just gi-gtk that is problematic | 13:29:45 |
| maralorn | Well the general problem is, that the nix derivation of a cabal package has no way to communicate any version bounds. | 13:29:55 |
| Las | Well I imagine all packages depend on a specific major version | 13:30:45 |
| Las | Since they are often incompatible with each other | 13:30:54 |
| maralorn | The question is: Where is the balance between hardcoding that for a certain package or doing it automatically for all packages. | 13:31:51 |
| maralorn | Generally doing that for all packages i.e. let them depend on aeson_1_5 and not on aeson would translate a lot of builderrors into eval errors. Also it would bloat nixpkgs by generating a lot of aliases. | 13:35:27 |
| maralorn | Still having a way to enable that for some packages would grant us a lot of flexibility … | 13:36:16 |
| maralorn | But not even sure if it would solve the haskell-gi problem. | 13:37:16 |
 cdepillabout | The Haskell team in Nixpkgs will helping people with hacking on Nix-related stuff at ZuriHac this year. The event is online and free, so we'd love to have everyone here participate if you're free: https://discourse.nixos.org/t/nix-and-haskell-at-zurihac-2021/13417 | 14:14:27 |
| Las | It's a shame that ZuriHac isn't also using Matrix | 14:36:57 |
| maralorn | Las: I have the fear that Matrix wouldn‘t be able to deliver the same voice/video-chat experience. | 14:38:01 |
| Las | maralorn: I don't think that's a fear, that's a fact | 14:40:16 |
| Las | Video chat still isn't very well developed on Matrix | 14:40:28 |
| Las | For 1-to-1 calls, it's very good though | 14:40:35 |
| Las | For multiple people, screen sharing, etc. it's lacking | 14:40:43 |
| maralorn | I haven‘t tried for quite a while. | 14:40:47 |
| maralorn | Oh, yeah. Screen sharing is probably a pain point. | 14:41:04 |
| Las | Jitsi integration is used for it after all | 14:41:32 |
| Las | I remember reading on HN some comment by Arathorn about them going to do something about it | 14:42:01 |
| Las | But that's probably a few months/years into the future | 14:42:17 |
| maralorn | And when I think about how difficult zoom calls with a few dozens of people can be when they have different zoom versions. I am a bit afraid of client diversity in that point. "Please vote with thumbs up. We have 8 different guides in our wiki …" | 14:43:02 |
| sterni (he/him) | In light of ZuriHac I wrote up my thoughts on platform handling in hackage2nix: https://github.com/NixOS/cabal2nix/issues/497 I plan to get to this eventually, but maybe someone else is motivated to start to work on it | 14:54:12 |
|  bqv changed their display name from bqv to qy. | 14:56:12 |
| bqv changed their display name from qy to bqv. | 14:56:14 |
