_module.public for standardized module return value?

[roberth]

Describe the feature

Many module system applications model a domain that can be thought of as a function.

Module system applications:

• For instance, NixOS is a function from all the other options to the values in system.build (whatever those may be).

• drv-parts has a public options that contains the produced package, achieving encapsulation by default, which is sorely missing in Nixpkgs (see cleanAttrs).

• The arion module system exists to generate a Compose file.

• flake-parts generates flake outputs.

Submodules:

• Freeform settings modules need a little fixup sometimes. Removing _module was universal which led us to bake that in; a behavior that could be considered the default implementation of _module.public instead.

Caveat

_module.public may make some information inaccessible (kind of the point with encapsulation, besides bringing some sanity to the engineering). Even the removal of _module has been a challenge at times.

Specifically:
For such things as built-in module system checks (assertions/warnings), we'll need an out of band channel, alongside <type>.merge. Doing this computationally effectively while keeping compatible is a challenge. This aspect should probably be in its own issue. TBD.
Similarly options is impossible to get from a submodule, without modifying the submodule. That's really bad for troubleshooting, because it's not always feasible, let alone easy to make such a change without disturbing the config you're inspecting.

Additional context

• [Reverted] Module-builtin assertions, disabling assertions and submodule assertions #97023

Notify maintainers

@infinisil, myself.

Also pinging @DavHau who wrote drv-parts. 👋