| 14 Feb 2024 |
 infinisil | Can't deny that! | 16:58:35 |
 Robert Hensing (roberth) | That's exactly why we need to burn it and start over with something manageable: a single fixpoint | 16:59:43 |
| Robert Hensing (roberth) | Each layer of fixpoint is expected to interact with each other layer. If they don't, that's a bug | 17:00:35 |
| Robert Hensing (roberth) | Let me refine that: if they completely don't, it's a missing feature that someone will want to use, in which case they'll write a partial implementation, which has bugs, because it doesn't interact with some of the other layers. | 17:01:31 |
| infinisil | Agreed. I don't want to stop others from trying to make small improvements, but personally I want to invest my energy into more future-proof designs | 17:05:55 |
| infinisil | There needs to be a balance though, can't always jump into all the rabbit holes.. | 17:06:35 |
| Robert Hensing (roberth) | I don't think the incremental improvements/fixes are particularly easy, so I wouldn't necessarily recommend to make them, but I won't stop those either | 21:49:49 |
| 17 Feb 2024 |
 @jade_:matrix.org | This looks interesting, for downstream consumers! https://discourse.nixos.org/t/nix-pkgset-cross-compilation-aware-flake-package-sets/39911 | 19:19:15 |
 @qyriad:matrix.org | Oh this looks fantastic 👀 | 19:32:45 |
| 20 Feb 2024 |
|  szlend joined the room. | 18:59:04 |
| szlend changed their display name from siyo to szlend. | 19:00:36 |
| 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 |
