Conditional module imports

Help
1

What’s a good easy way to conditionally import NixOS modules?

In my configuration I’ve got lots of little fairly self-contained NixOS modules which do something like:

  • install and configure several system tools
  • configure a postgresql server for development use
  • setup a basic desktop environment
  • … et cetera.

I want to enable and disable these modules on various machines at various times.

The standard way to do this would be to have each machine’s NixOS configuration import just the modules that it needs.

But at this point, I’ve got so many modules that I also want to make groups of modules which can be enabled together (while still retaining the ability to control individual modules). It’s getting messy.

So the standard way to solve this is to define my own NixOS options which enable individual groups and sub-groups of configuration. I have done this a little bit and it helps.

It’s getting tedious, however. Many modules would take the form:

# ./modules/this.nix
{ lib, config, pkgs, ... }: {
  options.me.install.this = lib.mkEnableOption "install and configure this";
  config = lib.mkIf config.me.install.this {
    # ...
   };
}

I really just want something like:

# ./modules/wrong.nix
{ config, lib, ... }: {
  options.me = with lib; {
    install = {
      system-tools = mkEnableOption "install and configure basic system tools";
      dev-db = mkEnableOption "setup postgresql for development";
      desktop = mkEnableOption "desktop environment configured how i like it";
      # etc
    };
    tasks = {
      dev = mkEnableOption "dev stuff relevant to me";
      # etc
    };
  };
  config = lib.mkIf config.me.tasks.dev {
    me.install.dev-db = lib.mkDefault true;
    me.install.compiler-and-tools = lib.mkDefault true;
    me.install.emacs = lib.mkDefault true;
  };
  imports = [ ./modules/base.nix ]
    ++ lib.optional config.me.install.system-tools ./modules/system-tools.nix
    ++ lib.optional config.me.install.dev-db ./modules/dev-db.nix
    ++ lib.optional config.me.install.desktop ./modules/desktop.nix;
}

But as we all know, module imports cannot depend on config, because that would cause infinite recursion.

What I’m trying now is to generate modules which wrap other modules with a mkEnableOption conditional. It seems to work, but I haven’t tested it extensively.

Here is an example. It will import all modules ./fragments/*.nix and create me.fragments.*.enable options for them.

# flake.nix
{
  description = "Ad-hoc config snippets";

  outputs = { self, nixpkgs }: let
    inherit (nixpkgs) lib;

    fragmentModules = attrPath: dir: extraSpecialArgs:
      lib.mapAttrsToList
        (makeFragmentModule attrPath extraSpecialArgs)
        (dirAttrs dir);

    makeFragmentModule = attrPath: extraSpecialArgs: name: path: let
      enableAttrPath = attrPath ++ [ name "enable" ];
    in args@{ config, ... }: {
      _file = path;
      key = path;
      options = lib.setAttrByPath enableAttrPath (lib.mkEnableOption "${name} fragment");
      config = lib.mkIf
        (lib.getAttrFromPath enableAttrPath config)
        (lib.applyModuleArgsIfFunction "fixme" (import path) (args // extraSpecialArgs));
    };

    dirAttrs = path: lib.mapAttrs'
      (name: _: nixFileAttrInPath path name)
      (lib.filterAttrs
        (name: type: lib.hasSuffix ".nix" name && type == "regular")
        (builtins.readDir path));
    nixFileAttrInPath = path: name: {
      name = nixFileAttrName name;
      value = path + "/${name}";
    };
    nixFileAttrName = path: lib.removeSuffix ".nix" (builtins.baseNameOf path);

  in {
    nixosModules.default = {
      imports = fragmentModules ["me" "fragments"] ./fragments { flake = self; };
      options.me.tasks = with lib; {
        dev = mkEnableOption "dev stuff relevant to me";
        laptop = mkEnableOption "it's a computer with a gui";
      };

      config = lib.mkMerge [
        (lib.mkIf config.me.tasks.dev {
          me.fragments.dev-db.enable = lib.mkDefault true;
          me.fragments.compiler-and-tools.enable = lib.mkDefault true;
          me.fragments.emacs.enable = lib.mkDefault true;
        })
        (lib.mkIf config.me.tasks.laptop {
          me.fragments.system-tools.enable = lib.mkDefault true;
          me.fragments.desktop.enable = lib.mkDefault true;
        })
      ];
    };

    nixosModules.tethys = {
      me.tasks.laptop = true;
      me.tasks.dev = true;
    };

    nixosModules.server = {
      me.tasks.dev = true;
      me.tasks.web = true;
      me.fragments.system-tools.enable = true;
      me.fragments.dev-db.enable = false;
    };

    nixosConfigurations = {
      tethys = nixpkgs.lib.nixosSystem {
        system = "x86_64-linux";
        modules = [
          ./tethys/hardware-configuration.nix
          self.nixosModules.default
          self.nixosModules.tethys
        ];
      };
      server = nixpkgs.lib.nixosSystem {
        system = "x86_64-linux";
        modules = [
          ./server/hardware-configuration.nix
          self.nixosModules.default
          self.nixosModules.server
        ];
      };
    };
  };
}

Surely someone is doing something like this already. Maybe I have overlooked something in the NixOS documentation. Perhaps there is a nice little library I can import?

1 Like
2

Don’t do conditional imports - import everything and then just toggle things on and off.

The pattern that I have been using for work (and personally for that matter):

  • a machine has one role (and one role only - prometheus server instance, mail relay, ruby based application server, etc)
  • a role has one or more profiles
  • a profile has one or more programs/services

Everything happens as if it’s a regular nixos module.

2 Likes
3

I do something sort of like this in my flake.nix by specifying different selections of modules to import based on specialArgs defined at a system level.

I can’t speak to doing this without flaking and by no means am I an expert. If someone can present me a better way to handle this or even just a reason not to I’m all ears.

displayConfig and nvidia_bool are the specialArg values responsible for the conditional imports.

# flake.nix
# Hyprland Desktop - 3 monitors 
    nixosConfigurations.retis = nixpkgs.lib.nixosSystem {
      system = "x86_64-linux";
      specialArgs = {
        username = "eriim";
        hostname = "host1";
        displayConfig = "3monitor";
        nvidia_bool = "enabled";
      } // attrs;        
      modules = [
            ./.
          ];
    };#retis

    # Hyprland Laptop 
    nixosConfigurations.sisyphus = nixpkgs.lib.nixosSystem {
      system = "x86_64-linux";
      specialArgs = {
        username = "eriim";
        hostname = "host2";
        displayConfig = "1monitor";
        nvidia_bool = "disabled";
      } // attrs;        
      modules = [
            ./.
          ];
    };#sisyphus

I then import based off the values of the specialArgs like so:

#  ./modules/module_with_conditional_import.nix
{ pkgs, displayConfig, home-manager, username, ... }:
let
  dotfiles = {
    "1monitor" = [ (import ./1monitor.nix { inherit home-manager username; }) ];
    "3monitor" = [ (import ./3monitor.nix { inherit home-manager username; }) ];
  };
in
{
  imports = [  ] ++ (dotfiles.${displayConfig} or [ ]); 
}

{ hyprland, pkgs, nvidia_bool, username, ... }:
let
  hyprNvidia = {
    "enabled" = [ (import ./nvidia.nix) ];
    "disabled" = [ ];
    };
in
{
  imports = [
    hyprland.nixosModules.default
    ./config
    ./greetd
    ./mako
    ./swaylock
    ./waybar
    ./wofi
  ] ++ (hyprNvidia.${nvidia_bool} or [ ]);

 ...

Is it clean? I honestly dont know. Does it work? Yes it seems to.

4

Spent time years ago trying to figure this out only to realize it basically just always leads to infinite recursion, since it has to evaluate the module to find out if it needs to import, so that it can evaluate, so it can determine if it needs to import… yeah, hopefully you see the problem.

Thankfully, it’s easy to just make a simple foo.enable option for your self contained modules and just toggle their behavior on or off with a simple boolean, like pretty much all the NixOS modules in nixpkgs. I don’t do that either, however, instead I just explicitly import all the modules I want per machine, at the top-level, just to have a clean list of what’s enabled on what system at a glance.

5

would you mind sharing an example of this kind of approach?

6

Yes agreed - I eventually realised that it’s less confusing to import all modules then use options to toggle them.

I like this terminology - thanks for defining it. I found some more info about it in the Puppet 8 Docs and Puppet Enterprise Guide. What’s called a “component module” in Puppet would correspond to an attrset of options like networking.firewall or services.apache, right?

In one Puppet doc, it states that a profile can include other profiles. In the other, the diagram implies that only a role can include profiles. I prefer the arrangement where profiles can include other profiles.

I guess what I was meaning to ask is whether there is an easier way of declaring NixOS options for each profile.

In my config, I have at least 150 .nix files which are profiles. So it’s a lot of error-prone work to surround each one with an option like this:

{ lib, config, pkgs, ... }: {
  options.me.profiles.this = lib.mkEnableOption "install and configure this";
  config = lib.mkIf config.me.profiles.this {
    # ... profile config here ...
   };
}
7

Yeah, that works. I have done a similar thing with specialArgs at times. In that situation, I had some machines which included home-manager and others which didn’t. But I feel using specialArgs like this breaks modularity.

8

I liked the simplicity of having a modules list per machine. But I also want modules (i.e. profiles) which include other modules (i.e. profiles including profiles). When the profiles list isn’t flat, it starts to get messy.

Edit: Maybe someone will ask - (a) why not just make the profiles list flat, or (b) why not just arrange profiles into a neat tree? I found these options too rigid because my config is always expanding and changing. As an example, I have profiles for GNOME, xmonad, and xfce desktop environments. One role has xfce, another has GNOME, and another has both GNOME and xmonad. They also share various config. For example, all three include the same Firefox config.

1 Like