If this is an option you're designing today, then you can work-around the limitations with a combination of option-level apply and reading valueMeta to access the actual submodule configuration's evaluated options.

It'd be ugly, but you could in theory filter out attributes whose corresponding option isDefined→false. If you have nested options you may end up with some empty attrsets, though, which would be hard to distinguish from option-remnants and empty freeform definitions.

In reply to @toonn:matrix.org
Yeah, trying to make the schemas as accurate as possible.

As an aside, I've found that in rfc42 style settings-options, the more explicit sub-options you declare the more maintenance debt you're signing up for.

Every declared option has to be kept in sync with changes to upstream's docs and schema.

IMO it's better to lean on freeformType and allow users to define anything they like, without you having to maintain a nix-representation of the schema.

In reply to @toonn:matrix.org
I'll look into isDefined though, thanks for the help!

In reply to @toonn:matrix.org
Darn, so that's gonna already bite me in the behind.

It shouldn't bite you. submodule supports v2, as do most composite types. One exception is nullOr is still stuck on v1.

To be clear, we're talking about the submodule option, not its sub-options; sub-options don't need valueMeta or v2 checkAndMerge unless you want to be recursively walking into submodules within submodules.

Here is a workaround i used for that:

modules = (opt.definitions ++ opt.type.getSubModules);
submoduleEval = lib.evalModules {
    inherit modules;
};