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.
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.
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.
addresses https://github.com/LnL7/nix-darwin/issues/1043
fix: use exec in launchd daemon config
fix: dont use a script thats in the nix store
fix: remove manual wait4path in linux-builder
fix: remove manual wait4path in karabiner elements
fix: remove manual wait4path in nix-daemon
fix: remove manual wait4path in nix-optimise
fix: remove manual wait4path in tailscaled
fix: autossh test
Revert "fix: remove manual wait4path in nix-daemon"
This reverts commit 6aec084fa5d095666e81676e78f7054c83703faa.
fix: remove bad exec
Reapply "fix: remove manual wait4path in nix-daemon"
This reverts commit c8f136ecc555f803124af471324bc6ed1163d6dd.
fix: update autossh test
to reflect changes in f86e6133d957becb1958da638516b0860fbd7491
fix: services-activate-system-changed-label-prefix test
fix: services-buildkite-agent test
fix: services-activate-system test
fix: escape ampersand
fix: services-lorri test
fix: services-nix-optimise test
fix: services-nix-gc test
refactor: use script rather than command in daemon
fix: use config.command for clarity
style: fix indentation
fix: use lib.getExe rather than directly pointing to file
revert: a87fc7bbbbdb7c25c5ad6721c93990ea035affdd
- mistaken refactor meant that service waited for nix store and not the relevant path
Shellcheck complains:
> args=(
> ^-- SC2054 (warning): Use spaces, not commas, to separate array elements.
Quote the --labels argument to resolve.
Signed-off-by: Sirio Balmelli <sirio@b-ad.ch>
As `/run` gets recreated every reboot and we can't specify dependencies
for launchd, creating the `workDir` every reboot will require extra
complexity with a separate daemon that runs as `root` otherwise it won't
have sufficient privileges.
As we clean the `workDir` when the service first starts anyway, it ends
up being the same.
