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?
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.
Currently, setting `homebrew.masApps` causes `"mas"` to automatically
be added to `homebrew.brews`. Users who want to use Homebrew only
for managing App Store apps and casks, like me, can override this
by setting `homebrew.brews = lib.mkForce [ ];` and adding Nixpkgsā
`mas` to their `environment.systemPackages`.
When the activation script path no longer depends on the built
configurationās `environment.systemPackages`, this will no longer
work. Since this was originally added before `mas` was packaged in
Nixpkgs and we now have a perfectly serviceable binary package,
we can add it to the `$PATH` when invoking Homebrew and skip the
automatic formula installation.
As the Homebrew `bin` directory still comes first, users who
specifically want the formula can restore the previous behaviour by
explicitly adding `"mas"` to `homebrew.brews`.
Closes: #1314
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.)
