| 11 Jul 2023 |
 @profpatsch:augsburg.one | nbp: what do you mean by “delegation of properties”? | 13:04:06 |
 nbp | mkIf cond { foo = …; } ==> { foo = mkIf cond …; } | 13:05:14 |
| nbp | mkIf cond { a.b.c.d.e.f.g.h.i = …; } ==> { a = mkIf cond { b.c.d.e.f.g.h.i = …; }; } ==> … ==> { a.b.c.d.e.f.g.h.i = mkIf cond …; }
What I am saying is that we could remove the intermediate steps. | 13:08:10 |
| @profpatsch:augsburg.one | nbp: how would you remove those steps? You have to go layer by layer, no? | 13:22:16 |
| @profpatsch:augsburg.one | > This transform is the critical step that allows mkIf conditions | 13:23:02 |
| @profpatsch:augsburg.one | to refer to the full configuration without creating an infinite | 13:23:02 |
| @profpatsch:augsburg.one | recursion. | 13:23:02 |
| @profpatsch:augsburg.one | That’s exactly what I mean, this is too much power | 13:23:10 |
| @profpatsch:augsburg.one | the semantics of a system like that shouldn’t be “you can refer to any option in any module at any time as long as you don’t create cycles” | 13:23:34 |
| @profpatsch:augsburg.one | Maybe a DAG-like structure or even a tree-like structure should be allowed, but a fixed point is too much to be able to optimize | 13:24:06 |
| nbp | The problem is not the fixed-point. This is like saying there is a for-loop, we should remove the loop and explicit every step done by the for-loop. | 13:25:56 |
| nbp | Yes, this gives power, and that's what makes NixOS modules great. Otherwise this would be called Guix, and you could only access things that were given to you as options that you could forward … but this would be worse, because either someone would forget to give you the option, or you will have to check for a ton of empty options provided to you. | 13:27:28 |
| @profpatsch:augsburg.one | The problem wouldn’t exist if there was no fixpoint | 13:27:33 |
| nbp | If there was no fix-point, then you will have the same problem, except that you would not be able to blame it on the fix-point. | 13:28:16 |
 raitobezarius | nbp: curious about this SOS draft | 13:29:50 |
| raitobezarius | Is this going to be developed in the public :> ? | 13:30:06 |
| @profpatsch:augsburg.one | yes, what I’m saying is nixos would be better off if modules had defined inputs and outputs | 13:30:37 |
| raitobezarius | (have you considered looking into Tvix too? It may be easier to do large scale changes depending on what you are interested, but it has some bugs and it's not cppnix) | 13:30:40 |
| nbp | At the moment my head is not public. :P | 13:30:42 |
| @profpatsch:augsburg.one | And if modules could only forma DAG | 13:30:45 |
 @piegames:matrix.org | A couple of years ago, I did some experiments with a module system where modules had a strict dependency graph onto each other. Turns out that you need at least some amount of cycles for things to be powerful enough. However, I think that such an explicit graph structure might allow for some interesting performance optimizations | 13:30:56 |
| raitobezarius | In reply to @nbp:mozilla.org
At the moment my head is not public. :P :) | 13:30:58 |
| @profpatsch:augsburg.one | piegames: right now you can’t even get the dependency graph out of the module system afaik | 13:31:30 |
| @profpatsch:augsburg.one | or if it’s possible I haven’t seen it done | 13:31:37 |
| @piegames:matrix.org | Because instead of forcing the entire set of options to determine dependency cycles, you'd only have to do so on a more coarse per-module structure first, which is a lot less work. Then all the uninvolved modules could just be ignored | 13:31:40 |
| @profpatsch:augsburg.one | there’s no real way of telling what exactly is needed in practice without extracting that | 13:31:56 |
| nbp | Profpatsch: Outputs already exists, this is the config, inputs do not, and I am really sad, because the only alternative I had was a crazy maintainer script which gives you a graphviz file after adding throw expression to every option. | 13:32:33 |
| @piegames:matrix.org | In reply to @profpatsch:augsburg.one
piegames: right now you can’t even get the dependency graph out of the module system afaik I think it should be possible in theory to write a module system evaluator which extracts that data, but not sure to what purpose. | 13:32:57 |
| nbp | Profpatsch: You can get a dependency graph, with this old maintainer script. | 13:33:10 |
| nbp | Maybe it is still part of Nixpkgs, who know, I have not look in years. | 13:33:26 |
