Extensible Option Types: Addressing Configuration Challenges with Display Managers

restricted set of types, namely `enum` and `submodules` and any composed forms of them. Extensible option types can be used for `enum` options that affects multiple modules, or as an alternative to related `enable` options. As an example, we will take the case of display managers. There is a central display manager module for generic display manager options and a module file per display manager backend (sddm, gdm ...). There are two approaches we could take with this module structure: - Configuring the display managers independently by adding an enable option to every display manager module backend. (NixOS) - Configuring the display managers in the central module by adding an option to select which display manager backend to use. Both approaches have problems. Making backends independent can quickly become hard to manage. For display managers, there can only be one enabled at a time, but the type system cannot enforce this restriction as there is no relation between each backend's `enable` option. As a result, this restriction has to be done explicitly by adding assertions in each display manager backend module. On the other hand, managing the display manager backends in the central module will require changing the central module option every time a new backend is added or removed. By using extensible option types, it is possible to create a placeholder option in the central module ([Example: Extensible type placeholder in the service module](#ex-option-declaration-eot-service)), and to extend it in each backend module ([Example: Extending `services.xserver.displayManager.enable` in the `gdm` module](#ex-option-declaration-eot-backend-gdm), [Example: Extending `services.xserver.displayManager.enable` in the `sddm` module](#ex-option-declaration-eot-backend-sddm)). As a result, `displayManager.enable` option values can be added without changing the main service module file and the type system automatically enforces that there can only be a single display manager enabled. ::: {#ex-option-declaration-eot-service .example} ### Extensible type placeholder in the service module ```nix { services.xserver.displayManager.enable = mkOption { description = "Display manager to use"; type = with types; nullOr (enum [ ]); }; } ``` ::: ::: {#ex-option-declaration-eot-backend-gdm .example} ### Extending `services.xserver.displayManager.enable` in the `gdm` module ```nix { services.xserver.displayManager.enable = mkOption { type = with types; nullOr (enum [ "gdm" ]); }; } ``` ::: ::: {#ex-option-declaration-eot-backend-sddm .example} ### Extending `services.xserver.displayManager.enable` in the `sddm` module ```nix { services.xserver.displayManager.enable = mkOption { type = with types; nullOr (enum [ "sddm" ]); }; } ``` ::: The placeholder declaration is a standard `mkOption` declaration, but it is important that extensible option declarations only use the `type` argument. Extensible option types work with any of the composed variants of `enum` such as `with types; nullOr (enum [ "foo" "bar" ])` or `with types; listOf (enum [ "foo" "bar" ])`.

This section details Extensible Option Types, a feature for `enum` and `submodules` (and their compositions), useful for options across multiple modules or as an alternative to `enable` options. Using display managers as an example, it highlights issues with traditional methods: independent `enable` options can't enforce mutual exclusivity without manual assertions, and central module approaches require constant updates for new backends. Extensible option types solve this by allowing a placeholder in a central module and extensions in individual backend modules (e.g., GDM, SDDM). This enables adding new display managers without altering the main service module and automatically enforces that only one can be enabled. It also notes that only the `type` argument is used in these declarations and confirms compatibility with composed `enum` variants.