| 14 Feb 2024 |
 @qyriad:matrix.org | In reply to @infinisil:matrix.org
It's just really hard to make sure that there are no regressions This is unfortunately going to be true of any unification solution and all of the steps towards them :/ | 16:58:22 |
 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 |
