nixos-config/modules/nixos/profiles

Table of Contents

• What are profiles, really?
• Setting profiles conditionally

We’re 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. They’re 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, here’s an exhaustive list of namespaces you should avoid using them as much as possible:

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

• Any modules under workflows are not exactly prohibited to use profiles since they are all-encompassing modules that creates a desktop that may be composed of multiple modules. However, it is heavily discouraged. If used, be sure to put it under a check with _isfoodogsquaredcustom which is an extra argument passed to various profiles (e.g., NixOS, home-manager) as an optional part of the configuration. Take note that workflows are also exported in the flake output. ^[1]

• Really, anything that is being exported in the flake outputs (i.e., look for the attributes in nix flake show) unless explicitly stated like the case for workflows.

Setting profiles conditionally

Because the way how profiles are exported in the flakes (which is not at all), we cannot easily export modules that make use of them. For this, we have the _isfoodogsquaredcustom attribute passed as part of specialArgs (or something similar) to the NixOS configuration. The attribute is a boolean value and only used for checking if it’s going to be included as part of the holistic system. Take note it should be only enabled in this flake, outsiders shouldn’t set this variable in any way.

Here’s one way how to do it as shown in the following snippet of a NixOS module.

{ config, options, pkgs, lib, ... }@attrs:

{
  # ...

  config = lib.mkIf cfg.enable (lib.mkMerge [
    {
      # Some required parts here.
    }

    (lib.mkIf (attrs ? _isfoodogsquaredcustom && attrs._isfoodogsquaredcustom) {
      # Set profiles here.
    })
  ];
}

---

1. Overall, I don’t think it’s not much of a threat to set profiles in the workflow unless users that is not me have conspicuously similar setup to mine. It’s just discouraged to minimize stepping on as less as configurations as possible.