My solution:

let

  nixFilesInDirectory = directory:
    (
      map (file: "${directory}/${file}")
      (
        builtins.filter
          (
            nodeName:
              (builtins.isList (builtins.match ".+\.nix$" nodeName)) &&
              # checking that it is NOT a directory by seeing
              # if the node name forcefully used as a directory is an invalid path
              (!builtins.pathExists "${directory}/${nodeName}/.")
          )
          (builtins.attrNames (builtins.readDir directory))
      )
    );

  nixFilesInDirectories = directoryList:
    (
      builtins.concatMap
        (directory: nixFilesInDirectory directory)
        (directoryList)
    );
  # ...
in {
  imports = nixFilesInDirectories ([
      "${./programs}"
      "${./programs/terminal-niceties}"
  ]);
  # ...
}

snippet from the full source code: quazar-omega/home-manager-config (L5-L26)

credits:

I’m trying out Nix Home Manager and learning its features little by little.
I’ve been trying to split my app configurations into their own files now and saw that many do the following:

  1. Make a directory containing all the app specific configurations:
programs/
└── helix.nix
  1. Make a catch-all file default.nix that selectively imports the files inside:
programs/
├── default.nix
└── helix.nix

Content:

{
  imports = [
    ./helix.nix
  ];
}
  1. Import the directory (picking up the default.nix) within the home-manager configuration:
{
  # some stuff...
  imports = [
    ./programs
  ];
 # some other stuff...
}

I’d like to avoid having to write each and every file I’ll create into the imports of default.nix, that kinda defeats the point of separating it if I’ll have to specify everything anyway, so is there a way to do so? I haven’t found different ways to do this in various Nix discussions.

Example I’m looking at: https://github.com/fufexan/dotfiles/blob/main/home/terminal/default.nix

My own repository: https://codeberg.org/quazar-omega/home-manager-config

  • CorbinEnglish
    2·
    7 months ago

    I’m adding some code snippets from my homelab’s flake. Minor details are changed. Note how I have a core.nix and also separate files for adding Avahi (zeroconf) and SSH, and for fixing bufferbloat. I could have them as one file, but it’s easier to come back to them after several years this way. (bufferbloat.nix was last changed in December 2021, for example.)

    I know that some of this code style probably seems weird. Think of it as heavily inspired by Puppet, Chef, Ansible, HCL, etc.; when we are configuring a system, it is very very nice to be able to comment out a single line at a time.

    Click to see code!

    Some common modules, bundled into a NixOS module:

        commonModules = {
      imports = [
        nixpkgs.nixosModules.notDetected
        ./avahi.nix
        ./bufferbloat.nix
        ./core.nix
        ./ssh.nix
      ];
      nix.registry.nixpkgs.flake = self.inputs.nixpkgs;
      nixpkgs.config.packageOverrides = pkgs: {
        mumble = pkgs.mumble.override {
          pulseSupport = true;
        };
      };
      users.users.corbin = {
        isNormalUser = true;
        extraGroups = [ "wheel" ]; # Enable ‘sudo’ for the user.
      };
    };

    A NixOS machine definition:

          joker = nixpkgs.lib.nixosSystem {
        inherit system;
        modules = [
          commonModules
          ./joker/configuration.nix
          ./gl.nix
          ./sound.nix
          ./wifi.nix
          ./xserver.nix
        ];
      };
    • QuazarOmega@lemy.lolOPEnglish
      2·
      7 months ago

      I see, that’s really neat!
      So joker is the name for one of the machines right? If so, how do you select that particular section in the actual machine’s config?

      Also, the code style seems normal to me? I’m not very familiar with Nix though, so maybe that’s why I don’t spot the weirdnesses

      • CorbinEnglish
        2·
        7 months ago

        The flake exports look like outputs.nixosConfigurations.joker, each one matching a hostname. There’s a poorly-documented feature of nixos-rebuild where you can point it at a flake with --flake and it will try to use the configuration matching the current hostname. So, I make the flake available on each machine and customize it using the hostname. One flake, a dozen machines. Works well enough for a homelab but would not work for a large cloud deployment.