| 5 Dec 2023 |
|  @federicodschonborn:matrix.org changed their profile picture. | 00:38:06 |
|  @quantenzitrone:matrix.org changed their display name from qz to quazi [ˈkvaːzi]. | 19:14:19 |
| 6 Dec 2023 |
 infinisil | Making some progress with RFC 140: https://github.com/NixOS/nixpkgs/pull/272395 (still a draft, not ready for review, but the description gives the story) | 02:38:00 |
 Philip Taron (UTC-8) | infinisil: I love pkgs/by-name and I write Rust at work. I'd be glad to be code reviewer when you' | 05:01:31 |
| Philip Taron (UTC-8) | * infinisil: I love pkgs/by-name and I write Rust at work. I'd be glad to be code reviewer when you're ready. | 05:01:35 |
| infinisil | Philip Taron: Oh awesome, that would be very welcome, thanks! I'll mark it as ready to review when done :) | 05:12:01 |
| 12 Dec 2023 |
| infinisil | Nothing concrete, but just wanted to point out this issue: https://github.com/NixOS/nixpkgs/issues/273534 | 17:43:46 |
 tomberek | In reply to @infinisil:matrix.org
Nothing concrete, but just wanted to point out this issue: https://github.com/NixOS/nixpkgs/issues/273534 We keep seeing this. And the current flake usage makes this worse. I opened: https://github.com/nixpkgs-architecture/issues/issues/25 , still needs work and discussion. | 17:49:48 |
 Robert Hensing (roberth) | Braindump of an actually feasible module-like packaging method for Nixpkgs, if you're interested. https://github.com/NixOS/nixpkgs/issues/273815 | 19:46:52 |
 bew | Found an unfinished sentence starting with "This should not include redundant (and slow)" | 22:29:32 |
| Robert Hensing (roberth) | Thanks. Edited. That was going to be about mkDerivation package attr stuff and multi-outputs, but the latter got its own section. | 23:06:06 |
| 13 Dec 2023 |
 nbp | “Bring all packaging layers into a single fixpoint” This is already the case, unless you are thinking about the bootstrap of the compilers, which is something I wanted to at one point. | 10:09:14 |
| nbp | Nixpkgs is already a fix-point of merged functions (final: prev: { … }) | 10:13:53 |
| nbp | Robert Hensing (roberth): I think we disagree on what qualifies as a module system, and your definition already encapsulate Nixpkgs as a module system, as I understand it. | 10:23:11 |
| nbp | The core of the problem of override is that we have to peel the layers of executed functions in order to patch what was inside.
This can be avoided by not calling mkDerivation but making it an attribute in the attribute set which is used to define a package, and then add an extra phase in charge of evaluating packages by calling the attribute which holds the mkDerivation with the attribute set of the package. I was not able to see this extra phase in your brain dump.
| 10:26:48 |
| nbp | And if you follow all these minimal set of steps, you end-up with S.O.S. which comes with the idea that we need a better way of merging values together which does not involve repeating tons of // operators, just to override something within an attribute set. | 10:29:13 |
| Robert Hensing (roberth) | What I describe merely takes a concept from the module system and uses it on its own. I don't think I've defined anything. | 12:02:09 |
| Robert Hensing (roberth) | My proposal is smaller in scope, keeping mkDerivation-like calls in top-level and such. It only tries to solve problems within a single package. | 12:04:58 |
| Robert Hensing (roberth) | My proposal solves the problem of too many layers of abstraction, not the problem of override memory consumption or anything related to top-level. Nonetheless it may unify how packages are constructed, having less diverse calls in top-level etc, so it could be a stepping stone towards S.O.S. | 12:11:59 |
