| 20 Jul 2021 |
 David Arnold (blaggacao) | Gytis Ivaskevicius: fufexan what are your thoughts on merge any? this feels like a forward-compatibility layer towards nickel or alternatively a substitute of the module system merge semantics. | 18:14:45 |
| David Arnold (blaggacao) | * Gytis Ivaskevicius: fufexan what are your thoughts on lib.mergeAny? This feels like a forward-compatibility layer towards nickel or alternatively a substitute of the module system merge semantics. | 18:15:01 |
| David Arnold (blaggacao) | * Gytis Ivaskevicius: fufexan what are your thoughts on lib.mergeAny? This feels like a forward-compatibility layer towards nickel or alternatively a substitute of the module system merge semantics. So I wonder if we can give it more concise / niche semantics in the big theater of configuration merging. | 18:15:30 |
| David Arnold (blaggacao) | * Gytis Ivaskevicius: fufexan what are your thoughts on lib.mergeAny? This feels like a forward-compatibility layer towards nickel or alternatively a substitute of the module system merge semantics. So I wonder if we can give it more concise / niche semantics in the big theater of configuration merging. | 18:15:47 |
| David Arnold (blaggacao) | (also, iirc, mergeAny is not recursive which might bring surprises one day downstream) | 18:22:07 |
 @gytis-ivaskevicius:matrix.org | I dont think that mergeAny brings much value to existing nixpkgs ecosystem, or atleast I cant think of a usecase for it. And if it does - i feel like it should be copied over nixpkgs | 19:07:03 |
| @gytis-ivaskevicius:matrix.org | Also about that reverse domain, i recently had an issue with it | 19:07:16 |
