Skip to content
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

Merged
merged 11 commits into from
Feb 11, 2025

Conversation

emilazy
Copy link
Collaborator

@emilazy emilazy commented Jan 30, 2025

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.

Enzime
Enzime previously approved these changes Feb 2, 2025
Copy link
Collaborator

@Enzime Enzime left a 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

pkgs/darwin-uninstaller/configuration.nix Show resolved Hide resolved
tests/services-nix-daemon.nix Show resolved Hide resolved
tests/sockets-nix-daemon.nix Show resolved Hide resolved
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.
Enzime
Enzime previously approved these changes Feb 6, 2025
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.
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.
@emilazy
Copy link
Collaborator Author

emilazy commented Feb 7, 2025

Rebased to:

  • make the condition for the uninstaller output about restoring the Nix daemon more specific;

  • look for Nix specifically on the environment.systemPath and only add that specific directory to the activation path. This avoids most of the hermeticity pitfalls outlined in the previous commit at the cost of a bit of complexity – I already had something similar in the Plan stack, and I realized that (a) the fact that the installers install into root’s profile meant the previous way risked picking up an old Nix when Nix management is enabled and (b) including the environment.systemPath in the activation path on 24.11 seemed dodgy from a backwards‐compatibility point of view, so doing it this way seems preferable.

The fact that root can get an old unmanaged Nix in the default configuration due to $PATH ordering seems bad anyway, but a separate issue, and the new version is closer to how we’ll want to do it in future anyway, post‐user‐activation and trying to keep the activation environment pure.

@retrry
Copy link

retrry commented Feb 8, 2025

Hey, @emilazy, where could I read about The Plan and what that is? 🙂 saw it mentioned in at least couple PRs.

@emilazy
Copy link
Collaborator Author

emilazy commented Feb 8, 2025

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 sudo to run darwin-rebuild and likely setting system.primaryUser) but will clean up a bunch of internal stuff that has been bugging me for a long time, and pave a path towards the long‐term goals of aligning nix-darwin with the NixOS model of a user‐agnostic system manager and reducing duplication with projects like Home Manager.

@richban
Copy link

richban commented Feb 10, 2025

Hopefully this gets merged soon 👍

@emilazy emilazy merged commit a674621 into LnL7:master Feb 11, 2025
3 checks passed
@emilazy emilazy deleted the push-tzwxwyvonslk branch February 11, 2025 19:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants