| 11 Jul 2023 |
 profpatsch | 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 | 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 | 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 | 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 | 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 | piegames: right now you can’t even get the dependency graph out of the module system afaik | 13:31:30 |
| profpatsch | 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 | 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 |
| @piegames:matrix.org | Instead I suggest tucking on some dependency system onto the module system, and the evaluator now additionally checks that each module only references options which are declared as one of its dependencies. (That's the main part I did back then). | 13:33:39 |
| profpatsch | piegames: To confirm or reject the statement “you need to have some cycles to be powerful enough”, obviously | 13:33:41 |
| @piegames:matrix.org | In reply to @profpatsch:augsburg.one
piegames: To confirm or reject the statement “you need to have some cycles to be powerful enough”, obviously I mean, you could always design something that works without, which I tried, and it was no fun. I don't remember the exact issues I was running into though | 13:34:51 |
| nbp | Profpatsch: https://github.com/NixOS/nixpkgs/blob/master/nixos/maintainers/option-usages.nix You are lucky, it still exists! | 13:39:06 |
| @piegames:matrix.org | In reply to @profpatsch:augsburg.one
piegames: To confirm or reject the statement “you need to have some cycles to be powerful enough”, obviously I think you probably won't need it for most modules, but you might need it for some of the more "core" bits. Which is basically my point: with a coarse dependency graph which tracks that information, one would not pay the performance penalty of recursion unless where required. | 13:41:01 |
 infinisil | @room: The next meeting will take place in 30 minutes - meeting link - live stream - meeting notes | 13:57:35 |
| profpatsch | piegames: in that case maybe have a package abstraction that can merge multiple files, but not generically | 14:19:06 |
| profpatsch | I mean, ML has basically solved this problems with functors | 14:20:29 |
