A patch that replaced the original file with a symlink to nix store was
reverted because MacOS Network framework doesn't support symlinks for
the file.
The revert leaves the system without any /etc/hosts file at all though.
To fix this, an activation step is added to restore the original file
from .before-nix-darwin backup, if it exists.
Signed-off-by: Ihar Hrachyshka <ihar.hrachyshka@gmail.com>
When `nix.enable` is off, we don’t necessarily have an active
Nix installation, so there won’t necessarily be an active
`/nix/var/nix/gcroots` directory to link things into. NixOS just skips
this unconditionally when `nix.enable` is off, but that doesn’t
work well with a context in which we usually expect `nix.enable`
to be coupled with an unmanaged system installation of Nix.
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, setting `homebrew.masApps` causes `"mas"` to automatically
be added to `homebrew.brews`. Users who want to use Homebrew only
for managing App Store apps and casks, like me, can override this
by setting `homebrew.brews = lib.mkForce [ ];` and adding Nixpkgs’
`mas` to their `environment.systemPackages`.
When the activation script path no longer depends on the built
configuration’s `environment.systemPackages`, this will no longer
work. Since this was originally added before `mas` was packaged in
Nixpkgs and we now have a perfectly serviceable binary package,
we can add it to the `$PATH` when invoking Homebrew and skip the
automatic formula installation.
As the Homebrew `bin` directory still comes first, users who
specifically want the formula can restore the previous behaviour by
explicitly adding `"mas"` to `homebrew.brews`.
Closes: #1314
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.
Seems like this should be more robust, and it will work even
after the activation script purifies its environment. Apparently
it may treat `tmux` sessions like SSH ones, which may have
something to do with `reattach-to-user-namespace`/`pam_reattach`; see
<https://github.com/ChrisJohnsen/tmux-MacOSX-pasteboard/issues/78#issuecomment-1074543831>.
(My hope is that `pam_reattach` does the right thing here, but I
haven’t tested.)
