Sender | Message | Time |
---|---|---|
16 May 2025 | ||
I never acquainted with
| 19:49:57 | |
I believe the issue is the
| 19:52:25 | |
Some of the "container types" don't really check what's inside before being evaluated at a later stage. I believe this is the case for submodules, listOf and attrsOf . As a hack, you can add those checks with lib.types.addCheck . Same scenario with either and oneOf . | 19:53:46 | |
It's intentional that the submodule-type's check function is not very restrictive, since you can assign any module to a submodule and it is down to the submodule's configuration to evaluate and merge its own definitions internally. | 19:53:58 | |
E.g. foo = {} is a vaild definition, as is foo = { config, ... }: { } , as is foo = ./someModule.nix | 19:54:55 | |
| 19:57:21 | |
The other issue with marker options (
You don't know which marker is defined until all merging is done. In a simple case like this, you could refactor this as one submodule with both markers, and then add some extra logic/conditions within the submodule and/or in the optinon's final | 20:02:16 | |
Also ref https://discourse.nixos.org/t/problems-with-types-oneof-and-submodules/15197 | 20:03:59 | |
One way you could work around this is to add an internal
| 20:16:10 | |
Yeah, thought about that. One'd need access to all defs at once... | 20:18:26 | |
H'm, do I get a merged value as an input if I addCheck (submodule ...) (def: def?marker_a) ?I just tried adding { foo = { }; } before and after { foo.marker_b = ...; } and it still seems to work | 20:28:37 | |
I believe the attrs are merged before being typechecked. I suppose you could try adding a lib.trace inside the typecheck to verify? | 20:32:31 | |
For modules:
| 20:37:22 | |
*
For modules:
| 20:37:32 | |
This won't support Type checking is done before merging, but after resolving Type checking is used to determine which type to use for merging. | 20:39:18 | |
Aha, that makes sense 👍️ | 20:41:25 | |
Sounds like __result is least wrong? | 20:50:51 | |
* Sounds like __result is the least wrong? | 20:50:55 | |
H'm what if freeformType s are different? attrsOf a and attrsOf b | 20:53:42 | |
I believe the freeform type can be conditional on a marker option being defined without infinite recursion. | 20:58:27 | |
So long as the marker options are explicitly defined, they are resolved before freeform definitions | 20:59:14 | |
Not sure I should depend on this detail 😅 | 20:59:19 | |
* So long as the marker options are explicitly declared, they are resolved before freeform definitions | 20:59:26 | |
freeformType is itself an option (config._module.freeformType ), so it's not really an implementation detail | 21:00:17 | |
| 21:06:01 | |
_Note: stringifying an option will use it's showOption opt.loc location, so you'll automatically get the full option prefix, e.g. "foo.marker_b" | 21:07:27 | |
* Note: stringifying an option will use it's showOption opt.loc location, so you'll automatically get the full option prefix, e.g. "foo.marker_b" | 21:07:39 | |
Awe and horror | 21:41:09 | |
I suspect this works and then gets rejected by some kind of a final type check: error: The option marker_a' was accessed but has no value defined. Try setting the option` | 22:04:36 | |
* I suspect this works and then gets rejected by some kind of a final type check: error: The option `marker_a' was accessed but has no value defined. Try setting the option | 22:04:51 |