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.
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.
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>
We already put `/nix/var/nix/profiles/default/bin` on the `$PATH`,
and whatever `nix.package` is set to already gets installed into
`/run/current-system/sw/bin`, so this is pointless.
For Nix 1, some environment variables were set when using distributed
builds requiring the Nix daemon to be managed by nix-darwin. However,
support for Nix 1 has been removed and no other environment variables
for Nix are set by default.
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
Currently there are a bunch of really wacky hacks required to get
nixpkgs path correctly set up under flake configs such that `nix run
nixpkgs#hello` and `nix run -f '<nixpkgs>' hello` hit the nixpkgs that
the system was built with. In particular you have to use specialArgs or
an anonymous module, and everyone has to include this hack in their own
configs.
We can do this for users automatically.
NixOS/nixpkgs@e456032add
Co-authored-by: Antoine Cotten <hello@acotten.com>
