| 28 Nov 2023 |
 profpatsch | As far as I understand, the module list order determines the merging order | 13:51:43 |
| profpatsch | like, for example, if you have a list that merges its element via append, the order of module imports will determine which elements are first in the resulting list | 13:56:57 |
 infinisil | Robert Hensing (roberth): tomberek: Growpotkin: John Ericson: DavHau: phaer: Meeting time: https://meet.jit.si/nixpkgs-architecture | 14:01:53 |
 problems | https://github.com/nixpkgs-architecture/issues/issues/24 | 15:08:34 |
 nbp | Profpatsch: Well given that the order is left unspecified such that each module can import in which ever order, the serialized DAG is unknown to the end user. | 18:23:11 |
| nbp | Within a module, you have no idea which of the import came before, nor which will come after, without having a global knowledge. | 18:23:56 |
| nbp | Whereas with override, you are supposed to master this fact to be in control of the desired output. | 18:24:37 |
 John Ericson | Oh shit sorry was afk on vacation and asleep then | 19:24:44 |
| infinisil | phaer: Did all the removal steps, thanks for joining the team, even just for a brief period! | 21:32:31 |
| 29 Nov 2023 |
| profpatsch | nbp: you are right of course | 09:11:39 |
| profpatsch | I don’t think the module system is a good fit for nixpkgs either, if just because of the slowness | 09:11:55 |
| 1 Dec 2023 |
|  b65be joined the room. | 19:41:52 |
| 4 Dec 2023 |
|  Philip Taron (UTC-8) joined the room. | 20:56:47 |
| 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 |
