When /nix/store internal directories get renamed, they just don't get
into the next version of your system closure and are thus no problem to
rename. But state in the system is a problem, as there is no process to
remov eit. Thus we need to do it ourselves.
(With some tweaks to handle `nix.enable` and order it at a more
sensible position in the `$PATH`.)
The installers actually install Nix into `root`’s profile for some
reason, which means that the path’s prioritization backfires when
the script runs as root and we’re managing the Nix installation. When
running `darwin-rebuild` as a normal user, this wasn’t a problem.
Maybe we should just have a check to make sure there’s no conflicting
Nix in `root`’s profile – it seems pretty bad for `root` to
get the wrong Nix – but it would trigger for almost everyone,
which seems kind of annoying. I guess we could automatically
remove it from `root`’s profile if it matches what’s in
`/nix/var/nix/profiles/default`…
This reverts commit 02232f71c5.
This backs out commit 3b738c765d.
Setting a `umask` made the parent directory have too conservative of
permissions making it so `_github-runner` couldn't access the child
directories.
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.
