| 14 Feb 2024 |
 9999years | but any decision that lets us move forward is a good one, regardless of if we standardize on lib.mkExtendDerivation or lib.makeOverridableGeneric | 16:54:59 |
 infinisil | Robert Hensing (roberth) previously described that there's about 7 layers of fixed-points for some derivations | 16:55:13 |
| 9999years | and to be honest the makeOverridable code is no easier to read & comprehend | 16:55:19 |
| infinisil | It's just really hard to make sure that there are no regressions | 16:55:44 |
 Robert Hensing (roberth) | fixed-points and potential fixed-points. Not all of them are properly exposed etc | 16:55:52 |
| Robert Hensing (roberth) | which is part of the problem | 16:55:56 |
| infinisil | It's so many intricasies | 16:56:01 |
| Robert Hensing (roberth) | https://github.com/NixOS/nixpkgs/issues/273815 | 16:56:13 |
 @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 |
