| 20 Feb 2024 |
 szlend | What's the purpose of the callPackage pattern really? Why does it expect a subset of packages as opposed to simply being the entire pkgs? Is it just so it can accept custom attributes? Some sort of performance reasons? | 20:21:38 |
| szlend | I know it does splicing as well, but that wasn't there originally right | 20:22:49 |
 K900 | It's a bit of a historical artifact | 20:23:12 |
| K900 | It doesn't really need to exist | 20:23:44 |
 Minijackson | right now, I think callPackage allows us to do overrides, and things like withFeature ? true | 20:26:22 |
| szlend | I see yeah, I've always just found the pattern inconvenient. I'd basically have to name all the packages twice. If I no longer needed one, I would forget to remove it from the function arguments. When I started with nix I always assumed it was the way to track dependencies between packages, but that's obviously not how it works. | 20:27:01 |
| K900 | The overrides bit is actually mkOverrideable | 20:27:08 |
| 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 |
