-
-
Notifications
You must be signed in to change notification settings - Fork 492
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nix: add nix.enable
option to disable Nix management
#1313
Conversation
c8baee4
to
005b98a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM apart from some minor nits
005b98a
to
598d8c6
Compare
I don’t think this is very important given the `nixPath` check, and it doesn’t fit very well into a post‐user‐activation world.
NixOS doesn’t bother doing this, and Nix already matches this conditional behaviour when `$NIX_REMOTE` is unset.
598d8c6
to
19d5f0e
Compare
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.
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.
We now manage the build users unconditionally when we manage the Nix installation.
We now manage the launchd daemon unconditionally when we manage the Nix installation.
19d5f0e
to
4d2a7ac
Compare
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.)
This provides a more useful error message than the `/etc/nix/nix.conf` hash mismatch error that would otherwise occur.
4d2a7ac
to
a2e44a8
Compare
Rebased to:
The fact that |
Hey, @emilazy, where could I read about The Plan and what that is? 🙂 saw it mentioned in at least couple PRs. |
The Plan is how we’ve been referring to the process I outlined in #1016 (comment) to address #96, for want of a better name :) I’ve finally been working on getting it done after promising to for years and should be able to push out a PR of the first stage some time next week. It should have relatively little impact on the user experience in the short term (beyond having to use |
Hopefully this gets merged soon 👍 |
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.
Note: This work was funded by Determinate Systems. The design is my own, based on discussions around the time of #1164 about simplifying our Nix management story.