Sender | Message | Time |
---|---|---|
19 Jun 2024 | ||
nbp | What is your problem? | 09:43:16 |
20 Jun 2024 | ||
@aadniz:knaben.org left the room. | 14:29:21 | |
21 Jun 2024 | ||
mr-qubo | Redacted or Malformed Event | 13:19:32 |
3 Jul 2024 | ||
k3ys joined the room. | 09:52:25 | |
4 Jul 2024 | ||
Philip Taron (UTC-8) left the room. | 15:46:22 | |
Philip Taron (UTC-8) joined the room. | 15:54:02 | |
5 Jul 2024 | ||
zrsk | Is it possible to override an option? I don't mean an option's value, I mean overriding the option itself, like changing the type or the default (I can't use extendModules ) | 15:24:32 |
7 Jul 2024 | ||
dminca joined the room. | 09:38:54 | |
8 Jul 2024 | ||
nbp | zrsk: By default, no, you can extend some option types such as enum and submodules , but you cannot substitute the type by another one. However, you can disable the module (using disabledModules = [ <path-of-imported-module> ] ) and re-implement the same interface as the disabled module. | 10:48:59 |
nbp | disabledModules was introduced as a way to develop non-backward compatible changes without having the fork NixOS. | 10:49:44 |
zrsk | nbp: Yeah I know about disabledModules , it would be nice if there was a way to disable single options and then re-implement them.Anyway at the end I solved my problem (which was unrelated, my question here was due to a possible workaround I was considering). To be exact what I wanted to do was changing the default value for an option and I don't mean using mkDefault , I mean changing the value in options.foo.default without having direct access to where it was declared (I'm generating docs starting from imported modules but the default value for that option was a package that required an overlay I didn't want to apply, otherwise it gave an evaluation error) | 12:27:43 |
nbp | We do not have a way apart from disabledModules for replacing the default value for the documentation :/ | 12:35:53 |
zrsk | In reply to @nbp:mozilla.orgThat's not the end of world | 12:41:53 |
zrsk | While I'm at it I've another question about the module system: why it isn't possible to set an option config.foo to a function of config.foo ? | 12:44:57 |
zrsk | In general it shouldn't lead to an infinite recursion | 12:45:23 |
zrsk | Or maybe yes, I'm not sure anymore...I remember thinking about this time ago. The example I was giving to myself was something like foo = f config.foo where f is the usual recursive factorial. But thinking about it now I can't see how I could express the recursion base case. | 12:48:22 |
zrsk | But still I believe that even foo = g config.foo with g: _: 42 as the constant function would lead to an infinite recursion error (perhaps I'm wrong, haven't tried) | 12:49:16 |
zrsk | * But still I believe that even foo = g config.foo with g = _: 42 as the constant function would lead to an infinite recursion error (perhaps I'm wrong, haven't tried) | 12:50:03 |
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 |