nixos-config/modules/nixos/_private/suites
2024-08-25 19:12:09 +08:00
..
archiving.nix modules: rename suites private module in the filesystem 2024-01-22 14:52:00 +08:00
browsers.nix modules: rename suites private module in the filesystem 2024-01-22 14:52:00 +08:00
desktop.nix nixos/modules: make config up-to-date 2024-07-16 13:49:36 +08:00
dev.nix nixos/suites: add programs 2024-08-25 19:12:09 +08:00
filesystem.nix nixos/suites: add programs 2024-08-25 19:12:09 +08:00
gaming.nix nixos/suites/desktop: modularize submodules into dedicated profiles 2024-01-25 18:52:07 +08:00
i18n.nix nixos/suites/i18n: update to be null by default 2024-06-26 12:31:33 +08:00
README.adoc modules: rename suites private module in the filesystem 2024-01-22 14:52:00 +08:00
server.nix modules: rename suites private module in the filesystem 2024-01-22 14:52:00 +08:00
vpn.nix modules: rename suites private module in the filesystem 2024-01-22 14:52:00 +08:00

Table of Contents

Were defining profiles after how digga library from divnix defines it. That is…

Profiles are a convenient shorthand for the definition of options in contrast to their declaration. Theyre built into the NixOS module system for a reason: to elegantly provide a clear separation of concerns.

— digga library

In other words, these are simple configuration that are typically composed of setting common NixOS options such as enabling NixOS services or installing system packages.

What are profiles, really?

However, unlike digga profiles, we do implement an interface (or a declaration) on top of the definition of options. Each profile should have an interface to be enabled first (e.g., options.profiles.${profile}) since it will be included as part of the included modules for our NixOS configurations. This basically makes it easier to create a centralized and one consistent version of a part of a configuration which we can just enable it anywhere multiple times. This also prevents potential problems that comes with importing a (digga) profile multiple times such as unintended merged values (i.e., duplicated items in a list).

Furthermore, they are not going to be exported to the flakes since they are quite specific and practically, no one is going to use them with each user having different requirements even with a cluster of systems. Thus, you should be mindful to use profiles whenever you write or update NixOS modules. As future reference, heres an exhaustive list of namespaces you should avoid using them as much as possible:

  • services and programs shouldnt use any profiles at all since they are small in scope that they are more likely to be combined with other modules.

  • Workflow modules (workflows) are prohibited to use profiles to discourage very customized configurations that are otherwise more suitable in the host, user, etc. We have host- and user-specific modules for those purpose.

  • Really, anything that is being exported in the flake outputs (i.e., look for the attributes in nix flake show).