Sure.
1 Like
Got it. I’ve since taken to looking at the function arguments as an alternative.
The same thing, the check happens after module collection, so the specifics of how and where the module that defines these options exists should not impact how the checks work. If you want to play around with my example or another without having to type everything for every iteration you could wrap the evalModules call in a thin function in the repl like:
f = module: (lib.evalModules { modules = [ { ... } module ]).config
and use
:p f { ... }
to quickly get feedback on what configuration the evaluation results in (:p recursively prints attrsets). Either attrsets, functions or paths can all be valid modules.
1 Like
Got it. So neither are technically supposed to work, correct…? I’d have to find an alternative.
With checks added to disqualify definitions for all but the last submodule type passed to either or oneOf using either of them is supposed to and does work.
Interesting… If I modify your example to look at the config attribute, I get the following error:
{ x = «error: The option `x.z' does not exist. Definition values:
- In `<unknown-file>': "bye"»; }
That’s right, because it’s specifying both x.y and x.z, which belong to typeA and typeB respectively, but if you remove either x.y or x.z it should work. The point of having both is just to demonstrate that it will not accept both options simultaneously, however will accept one.
The second module passed to evalModules in my example is what you would replace with your module argument if you’re making a function to test what different definitions yield.