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.)
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.
Seems like this should be more robust, and it will work even
after the activation script purifies its environment. Apparently
it may treat `tmux` sessions like SSH ones, which may have
something to do with `reattach-to-user-namespace`/`pam_reattach`; see
<https://github.com/ChrisJohnsen/tmux-MacOSX-pasteboard/issues/78#issuecomment-1074543831>.
(My hope is that `pam_reattach` does the right thing here, but I
havenāt tested.)
The description for options.nixpkgs.system already hints at this:
Neither ${opt.system} nor any other option in nixpkgs.* is meant
to be read by modules and configurations.
Use pkgs.stdenv.hostPlatform instead.
We can support this goal by not elaborating the systems anymore, forcing
users to go via pkgs.stdenv.
This will prevent problems when making the top-level package sets
composable in the next commit. For this to work, you should pass a fully
elaborated system to nixpkgs' localSystem or crossSystem options.
Backport of Nixpkgs commit 0a19371146130c0e2a402fd0c35f8283b0e81910.
Co-authored-by: Wolfgang Walther <walther@technowledgy.de>
The assertion message should include the `nixpkgs.config` value, however
it currently includes the entire `nixpkgs.config` _option_.
This means the type, declarations, definitions, etc were all printed.
Backport of Nixpkgs commit 1bd4da1848cb7b68858ebb2ca1f8b0e5fed46c58.
Co-authored-by: Matt Sturgeon <matt@sturgeon.me.uk>
Since the output of `lib.systems.elaborate` contains functions, an
equality check with `==` does not suffice, `lib.systems.equals` should
be used instead.
Backport of Nixpkgs commit 3794246066409d7baac72e3fdfb0e4f66ef4a013.
Co-authored-by: Jared Baur <jaredbaur@fastmail.com>
system and config shouldn't both be specified ā each will be filled in
based on the other when the system is elaborated.
Backport of Nixpkgs commit a3ba0495452cd8e72735ebd4472838e96902a259.
Co-authored-by: Alyssa Ross <hi@alyssa.is>
henrik-ch was also here :)
Backport of Nixpkgs commit 11406bdc0e5af9b3c8a8d597da23349238c65277.
Co-authored-by: Silvan Mosberger <silvan.mosberger@tweag.io>
Co-Authored-By: Valentin Gagarin <valentin.gagarin@tweag.io>
This is a common footgun people hit often. Remove it.
Backport of Nixpkgs commit ce87196a00214a0062ece1c3e03a9a97f563580f.
Co-authored-by: K900 <me@0upti.me>
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.
