Sender | Message | Time |
---|---|---|
8 Jul 2024 | ||
nbp | You are interested in making a fix-point within the module system. I never thought of it before. It is possible to make a fix-point within the apply function of an option, which how submodules are implemented, but using the option it-self …I doubt g = _: 42 would yield to an infinite recursion as config.foo would be evaluated lazify if the argument is used. | 12:59:48 |
zrsk |
You are right, just tried I guess I have to check how submodules are implemented | 13:25:18 |
@ktemkin:katesiria.org left the room. | 17:25:34 | |
9 Jul 2024 | ||
sbc64 joined the room. | 16:49:13 | |
14 Jul 2024 | ||
Tsomipa_ts joined the room. | 18:55:59 | |
15 Jul 2024 | ||
dminca changed their display name from dminca to nixpkgs. | 17:29:06 | |
dminca changed their display name from nixpkgs to dminca. | 17:42:43 | |
23 Jul 2024 | ||
Ezzobir Bezziou joined the room. | 08:21:01 | |
26 Jul 2024 | ||
Gaétan Lepage joined the room. | 15:30:55 | |
Matt Sturgeon joined the room. | 16:39:44 | |
27 Jul 2024 | ||
@brian:bmcgee.ie joined the room. | 11:20:49 | |
28 Jul 2024 | ||
Matt Sturgeon | Question: I.e. get definitions, metadata and final merged value for the freeform definitions separately from option definitions. Alternative: Motivation: Currently any sub-options defined will always show up in the resulting config, and we work-around this by having them default to This has two main downsides:
Instead, I would like to have sub-options without a default and have them not show up in the final config if they are not defined. I don't mind doing this manually, by merging the freeform value with any Follow up: Apologies for the long-form question! | 20:01:34 |
Matt Sturgeon | Maybe the correct implementation is to define any "optional" options outside the freeform submodule, and then copy them in if defined?
Perhaps submodule sub-options are only intended to be used when the value should always be in the generated value? | 20:41:12 |
Matt Sturgeon | * Maybe the correct implementation is to define any "optional" options outside the freeform submodule, and then copy them in if defined?
Perhaps submodule sub-options are only intended to be used when the value should always be in the generated value? | 20:41:39 |
29 Jul 2024 | ||
infinisil | Related: https://github.com/NixOS/nixpkgs/pull/63553 | 23:08:02 |
infinisil | And https://github.com/NixOS/nixpkgs/issues/158594 | 23:09:27 |
30 Jul 2024 | ||
Matt Sturgeon | Thanks, those links are insightful! I think 158598 is also related, but 158594 sounds like exactly what I want:
But it looks like the latest comment is backtracking or downscaling that idea... Playing around in the repl, I can get I guess to do this I would have to write my own Seems similar in principle to the | 00:34:08 |
Matt Sturgeon | * Thanks, those links are insightful! 158594 sounds like exactly what I want:
But it looks like the latest comment is backtracking or downscaling that idea... Playing around in the repl, I can get I guess to do this I would have to write my own Seems similar in principle to the | 00:34:48 |
Matt Sturgeon |
Or maybe this wouldn't work, if | 00:43:33 |
Matt Sturgeon | Seems it is: Would a PR be welcome to have | 01:20:44 |
Matt Sturgeon | Or maybe returning both config and definedConfig , the latter having filtered out declared options that aren't defined | 01:30:41 |
purepani joined the room. | 04:11:12 | |
31 Jul 2024 | ||
infinisil | @mattsturg:matrix.org Immediate thoughts are that it might be a bit of a leaky abstraction, but maybe also not. Feel free to make a PR, but I can't promise to get to review it myself soon, but perhaps @roberthensing:matrix.org can :) | 09:53:38 |
1 Aug 2024 | ||
cleverca22 joined the room. | 12:53:32 | |
4 Aug 2024 | ||
Traxys joined the room. | 13:40:51 | |
tacticaltaco joined the room. | 22:09:55 | |
9 Aug 2024 | ||
Matt Sturgeon | I've been playing around with this in this branch (current commit), but what I have now is infinitely recursive, because Is this approach fundamentally flawed? Do you have any suggestions for working around the inf-recursion? The immediate alternative that springs to mind is to pass both a I | 13:30:14 |
Matt Sturgeon | * I've been playing around with this in this branch (current commit), but what I have now is infinitely recursive, because Is this approach fundamentally flawed? Do you have any suggestions for working around the inf-recursion? The immediate alternative that springs to mind is to pass both a I | 13:30:54 |
Matt Sturgeon | * I've been playing around with this in this branch (current commit), but what I have now is infinitely recursive, because Is this approach fundamentally flawed? Do you have any suggestions for working around the inf-recursion? The immediate alternative that springs to mind is to pass both a
| 13:31:39 |
Matt Sturgeon | * infinisil Robert Hensing (roberth) Thanks for your support so far! I've been playing around with the concept in this branch (current commit), but my current implementation is infinitely recursive, because Is this approach fundamentally flawed? Do you have any suggestions for working around the inf-recursion? The immediate alternative that springs to mind is to pass both a
| 15:12:07 |