| 20 Feb 2024 |
 K900 | One thing callPackage does that you can't get with just mkOverrideable and ... patterns is checking for invalid arguments | 20:28:24 |
| K900 | Because e.g. ({ stdenv, foo, bar, ... }: { ... }) { stednv = ...; } is not an error | 20:28:54 |
| K900 | (same with override) | 20:29:13 |
 szlend | Personally I wish it was something more like ({pkgs, pythonPackages, crane}: ...). Basically package sets as inputs. Not sure where the extra args would fit in, but I always found it weird to mix these | 20:33:40 |
| K900 | That style would be harder to override | 20:34:04 |
 Minijackson | there was a proposition by amjoseph to pass pkgsOnBuild, pkgsOnHost, and so on: https://github.com/NixOS/nixpkgs/issues/227327 | 20:35:04 |
| Minijackson | makes cross-compilation much better, overriding much harder | 20:35:24 |
| K900 | Yeah that's basically just the no splicing proposal | 20:35:34 |
| szlend | Getting rid of is literally my #1 nixpkgs wishlist | 20:35:42 |
| szlend | * Getting rid of splicing is literally my #1 nixpkgs wishlist | 20:35:48 |
| K900 | I think we will be able to move into that direction a lot easier after the by-name migration | 20:36:08 |
| szlend | * Getting rid of splicing is literally #1 on my nixpkgs wishlist | 20:36:30 |
| K900 | Because then we can just do package-v2.nix or whatever with the new API | 20:36:39 |
| K900 | Without having to fight all-packages.nix merge conflicts for months | 20:36:59 |
| Minijackson | note that weirdly enough, splicing is a solution to the flake packages.${arch} issue: https://github.com/szlend/nix-pkgset | 20:37:02 |
| szlend | Yeah, this is just me trying to follow whatever patterns are established by nixpkgs because I didn't feel like reinventing the wheel | 20:37:39 |
| K900 | It's not | 20:37:44 |
| K900 | Well it kinda is | 20:37:51 |
| K900 | But it's still a hack | 20:37:55 |
| K900 | I have ideas but that's a conversation for much later | 20:38:06 |
| 26 Feb 2024 |
 Philip Taron (UTC-8) | infinisil: I'm on deck to take a look through your by-name PR today. It's hefty! | 17:27:46 |
 infinisil | Philip Taron (UTC-8): Thanks and agreed! | 17:29:10 |
| Philip Taron (UTC-8) | At work, we use a approve-commits model, instead of an approve-PR model, which makes the review process substantially lighter. I'm sad that GitHub doesn't let that happen, since I only get the chance to review the whole squashed PRs. | 17:30:02 |
| Philip Taron (UTC-8) | * At work, we use a approve-commits model, instead of an approve-PR model, which makes the review process substantially lighter. I'm sad that GitHub doesn't let that happen, since I only get the chance to review the whole squashed PR. | 17:30:04 |
| infinisil | I should create smaller PRs than this really 😅 | 17:30:42 |
| infinisil | Though if I do small PRs in parallel, I'd get a ton of merge conflicts. And if I do them in series, it would take a long time to make any progress | 17:31:38 |
| infinisil | Some middle ground is probably best | 17:32:17 |
| Philip Taron (UTC-8) | Yeah; I think the PR size is OK iff the reviewer can say yes/no on each commit. | 17:33:56 |
| Philip Taron (UTC-8) | That powers you to make targeted fixes on each commit, which makes the merge conflicts lower, which enhances the whole PR, in my experience. | 17:34:41 |
| infinisil | Oh yeah that sounds nice | 17:35:02 |
