-
-
Notifications
You must be signed in to change notification settings - Fork 18.6k
config-driven submodules? #158598
Copy link
Copy link
Open
Labels
0.kind: enhancementAdd something new or improve an existing system.Add something new or improve an existing system.2.status: stalehttps://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.mdhttps://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md6.topic: module systemAbout "NixOS" module system internalsAbout "NixOS" module system internals
Metadata
Metadata
Assignees
Labels
0.kind: enhancementAdd something new or improve an existing system.Add something new or improve an existing system.2.status: stalehttps://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.mdhttps://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md6.topic: module systemAbout "NixOS" module system internalsAbout "NixOS" module system internals
Fields
Give feedbackNo fields configured for issues without a type.
Projects
Status
No status
This assumes #158594 is implemented as an incremental change to the module system. I'm writing this as a separate issue to manage the scope; feel free to ignore this one.
For modules with large amounts of unset options, it is inefficient for module system evaluation to be guided by the opts, as the defs are significantly smaller value. In its early history, module system evaluation primarily traversed
config, but presumably, this was abandoned with the introduction of defaults in options.Making this mode of module evaluation available on an opt-in basis would allow large, frequently used submodules such as the ones in
systemdto be modeled more efficiently, providing documentation, type checking and merging for this important part of NixOS.Notify maintainers
@infinisil