Closes#1032
Add `"check"` to the `onActivation.cleanup` enum. When set, nix-darwin runs
`brew bundle cleanup` during system checks to detect Homebrew packages that
are installed but not present in the generated Brewfile. If extra packages
are found, activation fails with a list of them and remediation steps.
Unlike `"uninstall"` and `"zap"`, the `"check"` mode never removes packages
-- it only reports. This runs during both `darwin-rebuild check` and
`darwin-rebuild switch`, matching the behavior of all other system checks.
Add `enableBashIntegration`, `enableFishIntegration`, and
`enableZshIntegration` options that evaluate `brew shellenv` to set up
Homebrew's environment and shell completions. This automates the
boilerplate that every nix-darwin Homebrew user currently writes manually.
All three shells use `interactiveShellInit`, consistent with direnv and
home-manager conventions. Fish additionally sets up completions paths in
the same hook.
Whalebrew support was fully removed from Homebrew Bundle in
Homebrew 4.7.0 (Nov 2025). A `whalebrew` entry in a Brewfile now
raises `RuntimeError: Invalid Brewfile: undefined method 'whalebrew'`,
breaking the entire `brew bundle` invocation.
Use `mkRemovedOptionModule` so that existing configs get a clear
warning instead of an undefined-option error. Also removes the
auto-addition of `"whalebrew"` to `homebrew.brews` and the Brewfile
generation for Docker containers.
Add support for `cargo "pkg"` entries in the generated Brewfile. Homebrew
Bundle supports installing Rust crates via `cargo install`; the `rust`
formula is automatically installed if not already present.
Add support for `go "pkg"` entries in the generated Brewfile. Homebrew
Bundle supports installing Go packages via `go install`; the `go`
formula is automatically installed if not already present.
Both `brew bundle` formula and cask installers support a `postinstall`
option -- a shell command to run after the package is installed or
upgraded. The command only executes when the package actually changed,
not on every `brew bundle` run.
Examples from the Homebrew docs added to the `homebrew.brews` and
`homebrew.casks` option examples and tests.
Homebrew supports `link: :overwrite` which runs `brew link --overwrite`,
force-overwriting existing symlinks. Extract the existing
`restart_service` special-case logic into a reusable helper
(`mkBrewfileLineBoolOrSymbolString`) for options that can be either a
bool or a Ruby symbol in the Brewfile.
Adds a new `services.dnsmasq.servers` option to configure upstream DNS servers. This allows users to specify which DNS servers dnsmasq should forward queries to, supporting domain-specific routing and custom ports.
When empty (default), dnsmasq uses servers from /etc/resolv.conf.
Signed-off-by: Wigger Boelens <me@wigger.email>
I’m not *completely* certain that this handles user agents
correctly. There is a deprecated command, `launchctl asuser`, that
executes a command in the Mach bootstrap context of another user`.
<https://scriptingosx.com/2020/08/running-a-command-as-another-user/>
claims that this is required when loading and unloading user agents,
but I haven’t tested this. Our current launchd agent logic is pretty
weird and broken already anyway, so unless this actively regresses
things I’d lean towards keeping it like this until we can move
over entirely to `launchctl bootstrap`/`launchctl kickstart`, which
aren’t deprecated and can address individual users directly. Someone
should definitely test it more extensively than I have, though.
This adds an optional explicit `homebrew.user` option that allows users
to avoid setting `system.primaryUser`, partly as a proof of concept
of what the interfaces should look like in the future. Homebrew only
officially support one global installation, so a singleton matches
upstream’s expectations; in practice, it may be useful for us to
nest this into `users.users.*.homebrew` instead, at the expense of
being an unsupported setup if used to its full potential. Since
that would be a breaking change to the inteface anyway, I think
adding `homebrew.user` for now is acceptable. (I think one native
Apple Silicon and one Rosetta 2 Homebrew installation – under
`/opt/homebrew` and `/usr/local` respectively – may be exceptions
to this lack of upstream support, but that would be complicated to
support even with `users.users.*.homebrew`.)
I’m not entirely sure where in system activation this should
go. Probably after the user defaults and launch agents stuff, to match
the existing logic in user activation, and I lean towards doing it
as late as possible; too early and we might not have the users and
groups required to bootstrap a Homebrew installation set up, but
as Homebrew installations could be fiddly and fail, doing it in the
middle could leave a partially‐activated system.
Probably it should be done in a launch agent or something instead, but
this is my best guess as to the appropriate place for now. The downside
is that activation scripts generally won’t be able to assume that the
Homebrew prefix is populated according to the current configuration,
but they probably shouldn’t be depending on that anyway?
When we’re not managing the Nix installation, these defaults
aren’t used out of the box and won’t accurately represent the
state of any unmanaged Nix or the desired Nix package, so reading
the option defaults is a bug.
This was previously a warning for `nix.package` and a silent failure
for all the others. Now that all the problematic accesses in nix-darwin
have been appropriately conditionalized, and since a throw gives a
backtrace where a warning doesn’t, give throwing defaults to all the
`nix.*` options that don’t reflect reality and that that modules
shouldn’t be reading when `nix.enable` is off.
I’m not in love with the implementation strategy here… ideally
we’d think of something better than this and then upstream it to
NixOS. `nix.nrBuildUsers` growing a fake default that is never used
is particularly unfortunate. But this should hopefully catch mistakes
in module code reasonably reliably.
Currently, the `bin` directory of the configured system
is embedded in the `$PATH` of activation scripts, but not
other elements of the default `environment.systemPath` like
`/nix/var/nix/profiles/default/bin` or `/usr/local/bin`. This
means that when nix-darwin is not managing the Nix installation,
activation scripts like Home Manager’s that want to look up the
system‐managed Nix can’t find it. Search for it on the entire
`environment.systemPath` and add the appropriate directory if found.
We leave the launchd `activate-system` daemon alone, because it has
erroneously referred to `@out@/sw/bin` forever and therefore never got
a Nix on the path to begin with. That’s a problem for another time.
(The more ideal solution is probably for Home Manager activation to
be driven by launchd or something, but that’s a longer‐term goal.)
We now assume the daemon is used unconditionally when we manage the
Nix installation.
The `nix.gc` and `nix.optimise` services lose their `$NIX_REMOTE`
setting rather than making it unconditional, as the NixOS `nix.gc`
module does not set it. Possibly it should, but I think uniformity
between the two systems is better than diverging, even though I kind
of hate that the non‐daemon method of access is even a thing.
This is an equivalent of the `nix.enable` option from NixOS
and Home Manager. On NixOS, it mostly serves to allow building
fixed‐configuration systems without any Nix installation at
all. It should work for that purpose with nix-darwin too, and the
implementation is largely the same, but the main use case is more
similar to the Home Manager option: to allow the use of nix-darwin
with an unmanaged system installation of Nix, including when there
is another service expecting to manage it, as with Determinate.
By providing an escape hatch to opt out of Nix management entirely,
this will also allow us to consolidate and simplify our existing Nix
installation management, by being more opinionated about things like
taking ownership of the daemon and the build users. Porting one option
from NixOS lets us drop two that only ever existed in nix-darwin and
reduce overall complexity.
This adds support for the following defaults:
- com.apple.WindowManager.EnableTilingByEdgeDrag
- com.apple.WindowManager.EnableTopTilingByEdgeDrag
- com.apple.WindowManager.EnableTilingOptionAccelerator
