| 20 Jun 2024 |
|  Adnan Zaman 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.org
We do not have a way apart from disabledModules for replacing the default value for the documentation :/ That'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 |
I doubt g = _: 42 would yield to an infinite recursion as config.foo would be evaluated lazify if the argument is used.
You are right, just tried
I guess I have to check how submodules are implemented
| 13:25:18 |
|  [K]ate Temkin 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 |
|  BMG joined the room. | 11:20:49 |
| 28 Jul 2024 |
| Matt Sturgeon | Question:
In a submodule with a freeformType, how can one access the freeform definition (and option metadata) separately from any sub-options?
I.e. get definitions, metadata and final merged value for the freeform definitions separately from option definitions.
Alternative:
Is it possible to configure a submodule evaluation to only merge "defined" options into the final config value?
Motivation:
In nixvim, we have several freeform "settings" submodules, and we directly pass the resulting config to a toLua generator.
Currently any sub-options defined will always show up in the resulting config, and we work-around this by having them default to null.
This has two main downsides:
- When filtering out nulls, we also filter out any explicitly defined nulls.
- When we have options at nested attr paths, we have to filter out the empty attr after we filter the null
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 options.*.value where options.*.isDefined, but idk how to access the freeform value separately.
Follow up:
If I have to do this within the submodule, idk the best way to access the result from outside the submodule? I could declare an internal option definedConfig, but I'm not sure if I could avoid infinite recursion when merging the other option values into it?
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?
# Set settings.foo to foo, if defined
optionalAttrs options.something.foo.isDefined {
# Use mkDerivedConfig to also copy definition priority
something.settings.foo = lib.mkDerivedConfig options.something.foo (v: v);
}
Perhaps submodule sub-options are only intended to be used when the value should always be in the generated value?
| 20:41:12 |
