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
trying to fix#1142
testing requested changes
adding workspace to monitor force assignment
remove formatting
tests pass
proper tests
undo formatting
tests for on-window-detected and workspace-to-monitor-force-assignment
testing submodules
cleanup n if fiz
checking
final
toml null field aerospace callback issue
custom null filter for submodule list
check for no presense of window-regex and if.workspace config check
aerospace: add workspace-to-monitor-force-assignment option and fix
on-window-detected type #1208
trying to fix#1142
testing requested changes
adding workspace to monitor force assignment
remove formatting
tests pass
proper tests
undo formatting
tests for on-window-detected and workspace-to-monitor-force-assignment
testing submodules
cleanup n if fiz
checking
final
toml null field aerospace callback issue
custom null filter for submodule list
check for no presense of window-regex and if.workspace config check
error
formatting mishap
space left
small fix
formatting mishaps
Disabling this is not supported as `/run` gets cleared out on every
reboot so it is necessary for ensuring that the `/run/current-system`
symlink exists.
Using `grep -v` without `-z` will return 0 even if there is a match
found as all the non-matching lines will be matched. Instead of using
`grep -vqz`, `(! grep ...)` is more readable.
The brackets are necessary as `! grep` will not trigger `set -e`[0], so we
run it inside a subshell to use its non-zero exit code.
[0]: https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html#The-Set-Builtin
