Do we need to define machines in both the "darwin" and "home" subtrees?

[seh]

Both of the nix/darwin and nix/home directories contain parallel sets of machines, modules, and profiles directories. Assuming that I'm using macOS as my operating system, it's not clear to me yet whether one must always define configuration for a given machine in both the nix/darwin/machines and the nix/home/machines directories.

The "ci" machine in the nix/darwin/machines/ci.nix file appears to configure things for home-manager. The parallel nix/home/machines/ci.nix file is similar, but it also sets the "programs.home-manager.enable" attribute to true.

I assume that if we're not using nix-darwin, then we don't need the machine definition under nixt/darwin/machines. If we are using nix-darwin, though, do we also need the machine definition under nix/home/machines?

[seh]

Also, while we're here, why does nix/darwin/machines/ci.nix start with an arguments set, but nix/home/machines/ci.nix doesn't need to? It appears that they're both modules fed to the "modules" attribute of darwin.lib.darwinSystem and home-manager.lib.homeManagerConfigurations, respectively.

[midchildan]

As mentioned in the NixOS manual, a module is defined as a function that returns an attribute set.

{ config, pkgs, ... }:

{
  option = value;
}

Alternatively, you can use a plain attribute set instead of a function when you don't need any of the arguments.

{
  option = value;
}

Though the manual is for NixOS, the same thing applies to Home Manager and nix-darwin as well.

[midchildan]

Home Manager configuration in nix/home/machines and nix/darwin/machines are independent of each other. Which one to use depends on how you want to manage Home Manager.

nix/home/machines contains configuration for standalone Home Manager setups. This should be used if you want to manage Home Manager separately from nix-darwin. The example configuration in nix/home/machines/ci.nix enables the programs.home-manager module to include the home-manager CLI in the user profile.

nix/darwin/machines contains configuration for nix-darwin. You can optionally define your Home Manager configuration there, making it possible to build and manage your Home Manager configuration in lockstep with nix-darwin configuration. You can read more about nix-darwin/Home Manager integration here. My example configuration for nix-darwin doesn't enable programs.home-manager because the home-manager CLI shouldn't be used in such a setup.

[midchildan]

If I tried to skip this step, nix-darwin's darwin-installer program would fail, complaining about not finding what it needs from Home Manager.

nix-darwin doesn't have any dependency on Home Manager, so such a requirement can only come from configuration. So removing Home Manager stuff from the nix-darwin configuration would've made installing Home Manager unnecessary.

That failed due to problems with my ca-certificates.crt file, remedied with these commands:

That's odd, but there's just too many reasons certificate verifications could fail so it's hard to tell. Maybe you needed to source nix-daemon.sh after installing Nix, or open a new shell to do just that. /etc/ssl/certs/ca-certificates.crt
 is installed by nix-darwin, so it's also kind of weird that you had to remove it.

[midchildan]

Assuming a non-flake setup, only these two should've been necessary if you only wanted nix-darwin:

1. Install Nix
2. Install nix-darwin

[midchildan]

The steps I use is written here. Though on macOS, I also need to install Homebrew beforehand because I use Homebrew Cask and rely on nix-darwin to manage it.

[seh]

I studied this command from your documentation for a long while today, and ported the parts necessary to implement it into my repository:

nix --experimental-features 'nix-command flakes' run '.#os' -- switch --flake '.#'

I see how that makes the darwin-rebuild tool—among a few others—available, and uses it to build and activate the top-level default flake target. I have been running darwin-rebuild build --flake . or darwin-rebuild switch --flake . for a few days, given that I already have darwin-rebuild available on my path. If I understand your technique correctly, it doesn't require that darwin-rebuild is available already; instead, it makes it available.

[midchildan]

That's correct. The intention was to make bootstrapping easier.