This fixes an unnecessary evaluation dependency that prevented the
custom and much appreciated primaryUser error from popping up.
Specifically:
… while evaluating the option `system.build':
… while evaluating definitions from `/nix/store/lc6n4bhxj9255kzfn9pnpx65583a8cgc-source/modules/environment':
… while evaluating definitions from `/nix/store/lc6n4bhxj9255kzfn9pnpx65583a8cgc-source/modules/nix':
… while evaluating the option `environment.darwinConfig':
… while evaluating the option `system.primaryUserHome':
error: expected a string but found null: null
at /nix/store/lc6n4bhxj9255kzfn9pnpx65583a8cgc-source/modules/system/primary-user.nix:26:30:
25| default =
26| config.users.users.${config.system.primaryUser}.home or "/Users/${config.system.primaryUser}";
| ^
27| };
While it did have some indication as to the cause, it lets the good
error message go to waste.
**Context**
`lazyAttrsOf` is the better choice when you use an attrset as individual
variables instead of in aggregate (e.g. `attrNames`, `toJSON`).
The reason is that an expression like `a.b` is strict in `a`, which
entails the evaluating the _whole_ set of attribute _names_ in `a`.
In the `attrsOf` this means evaluating all `mkIf` conditions, which
in turn also means evaluating all the regular definitions to the
smallest degree (WHNF) to determine that they're not `mkIf`s.
`lazyAttrsOf` simply assumes that all attributes aren't `mkIf false`,
and throws an error in the attribute value if necessary.
This would be a problem with `toJSON` and such, but is completely
fine when the attributes are treated as variables of a lazy program,
as is the case here.
**NixOS**
NixOS made `system.build` a submodule with a `freeformType`, allowing
the things inside of it to be declared, and for them to have niceties
like documentation and merging behavior.
nix-darwin could probably adopt this.
These can’t be relied upon in a post‐user‐activation
world. Technically a breaking change, if anyone has their home
directory outside of `/Users` or is using `root` for this, but, well,
I did my best and these are legacy defaults anyway.
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 `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.
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 shouldn’t actually be split out from the Plan because of the
current use of `$HOME` in the defaults for channel‐based setups.
This reverts commit 4bff4bc8ae.
This ensures that system activation does not depend on various
details of its process environment, ensuring uniformity across various
invocation contexts and with the `activate-system` daemon. This becomes
more important in a post‐user‐activation world to avoid problematic
dependencies like `$SUDO_USER`, but is a good idea in general.
The `sudoers(5)` defaults on my Sequoia system are:
Defaults env_reset
Defaults env_keep += "BLOCKSIZE"
Defaults env_keep += "COLORFGBG COLORTERM"
Defaults env_keep += "__CF_USER_TEXT_ENCODING"
Defaults env_keep += "CHARSET LANG LANGUAGE LC_ALL LC_COLLATE LC_CTYPE"
Defaults env_keep += "LC_MESSAGES LC_MONETARY LC_NUMERIC LC_TIME"
Defaults env_keep += "LINES COLUMNS"
Defaults env_keep += "LSCOLORS"
Defaults env_keep += "SSH_AUTH_SOCK"
Defaults env_keep += "TZ"
Defaults env_keep += "DISPLAY XAUTHORIZATION XAUTHORITY"
Defaults env_keep += "EDITOR VISUAL"
Defaults env_keep += "HOME MAIL"
Of these preserved environment variables, the ones that are set in
practice when I run `sudo env` that aren’t set in the activation
script here are:
* `$COLORTERM`
* `$DISPLAY`
* `$EDITOR`
* `$MAIL`
* `$SSH_AUTH_SOCK`
* `$TERM`
* `$__CF_USER_TEXT_ENCODING`
Most of these seem either pointless or actively harmful to set for
the purpose of the system activation script.
This will mean that tools run during activation won’t print output
in the user’s preferred language, but that’s probably the right
trade‐off overall, as that is likely to break activation scripts
that parse command output anyway.
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.
This adds support for the following defaults:
- com.apple.WindowManager.EnableTilingByEdgeDrag
- com.apple.WindowManager.EnableTopTilingByEdgeDrag
- com.apple.WindowManager.EnableTilingOptionAccelerator
These are lists, not attribute sets, so the condition was always
succeeding. As far as I can tell this bug has been present since the
function was added.
