Why do we use merge // when we can just use imports in home-manager?

[Demianeen]

Experience with this template is awesome so far! I am just curious why author did this this way. In the template, darwin home-manager config uses // syntax to merge shared and darwin configs:

home-manager = {
    useGlobalPkgs = true;
    users.${user} = { pkgs, config, lib, ... }:
      {
        home = {
          enableNixpkgsReleaseCheck = false;

          packages = pkgs.callPackage ./packages.nix { };
          file = lib.mkMerge [
            sharedFiles
            additionalFiles
            { "emacs-launcher.command".source = myEmacsLauncher; }
          ];
          stateVersion = "23.11";
        };
        # FIXME:
        programs.man.enable = false;
      } // import ../shared/home-manager.nix {
        inherit config pkgs lib catppuccin;
      };
  };

I had a trouble with // overriding some of my darwin specific properties today, and found that I can just use imports instead of merging with //:

  home-manager = {
    useGlobalPkgs = true;
    users.${user} = { pkgs, config, lib, ... }: {
      imports =
        [ ../shared/home-manager.nix catppuccin.homeManagerModules.catppuccin ];
      home = {
        enableNixpkgsReleaseCheck = false;

        packages = pkgs.callPackage ./packages.nix { };
        file = lib.mkMerge [
          sharedFiles
          additionalFiles
          { "emacs-launcher.command".source = myEmacsLauncher; }
        ];
        stateVersion = "23.11";
      };
      # disable Home Manager's man in favor of Nix-Darwin's
      programs.man.enable = false;
    };
  };

The only issue I has so far with imports is that catppuccin.homeManagerModules.catppuccin in shared/home-manager was causing infinite recursion, but I fixed that just adding the same module to darwin and nixos imports directly.

So, considering that they even have a bit different behaviour, I am curious what is the advantage of the approach with merging?

[dustinlyons]

I think, at the time, I liked the idea of enabling overrides from shared modules within each platform-specific module. It's easy to override stuff in line with //. Moreover, I was running into infinite recursion errors and not solving them so easily. So I went this route.

Both implementations are fine with tradeoffs.

[Demianeen]

Do you know why normal import causes infinite recursion? While // does not?

[dustinlyons]

It has to do with order evaluation and attribute sets. The imports convention imports code immediately and adds it to the configuration.

Using //, you are effectively lazily creating a new attribute set when the option is accessed, as right hand side isn't evaluated right away.

// is creating a new attribute set where keys from right side override those from the left.