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.
It seems like this has been broken since
26bab2fd32 from 2018; macOS `diff(1)`
does not support these arguments and the `$PATH` has been fixed since
that point. Before that, it would presumably only have worked if you
added GNU diffutils to `environment.systemPackages`.
Proactively notifying users about breaking changes isn’t a bad idea,
but the activation script doesn’t seem like the right place for it,
and as it’s non‐blocking it’s likely that even if it worked it
would get drowned out by the later output anyway. I’d like to move
the changelog into release notes as part of the manual, which would
requires changes to this anyway. Since it’s been broken for almost
seven years anyway, let’s just drop it for now and revisit later.
Remove suggestion to set `nix.useDaemon` as it came without an
explanation of how the `nix-daemon` would be unmanaged and would most
likely lead to most users running an old version of Nix as the daemon.
This is hopefully largely cosmetic, but should increase user
confidence in the safety and effectiveness of the migration, and the
Determinate Systems and Lix installer commands will also update the
`/nix/receipt.json` files to match the changes made. They cannot
properly handle the format of each other’s receipts, so we need to
detect which was used.
Checking for the Sequoia stuff won’t work properly if a system is
still in this old state. Best to be loud about it to deal with any
straggler systems that haven’t yet dealt with this issue.
As explained in the changelog and activation check, the previous
implementation had a nasty security bug that made removing a user’s
authorized keys effectively a no‐op.
This process was automated by [my fork of `nix-doc-munge`]; thanks
to @pennae for writing this tool! It automatically checks that the
resulting documentation doesn't change, although my fork loosens
this a little to ignore some irrelevant whitespace and typographical
differences.
As of this commit there is no DocBook remaining in the options
documentation.
You can play along at home if you want to reproduce this commit:
$ NIX_PATH=nixpkgs=flake:nixpkgs/c1bca7fe84c646cfd4ebf3482c0e6317a0b13f22 \
nix shell nixpkgs#coreutils \
-c find . -name '*.nix' \
-exec nix run github:emilazy/nix-doc-munge/0a7190f600027bf7baf6cb7139e4d69ac2f51062 \
{} +
[my fork of `nix-doc-munge`]: https://github.com/emilazy/nix-doc-munge
According to some investigation creating "role" accounts avoids
migration problems when upgrading to certain macOS versions, so create
the build users to match that definition and remove the old ones if
present.
Role accounts require name starting with _ and UID in 200-400 range
This case will cause problems when existing files in /etc are replaced
instead of skipped with a warning, potentially breaking the nix install
in the process.
The nix.useDaemon option enables using a multi-user install without
managing the nix installation with nix-darwin. The following checks
apply to both cases.
