The Plan, phase 1 #1341

emilazy · 2025-02-16T02:12:28Z

It’s finally time.

This PR eliminates user activation, addressing #96 by following the first phase of the plan from #1016 (comment), fulfilling a goal I started drafting patches for in 2023 before I was even a nix-darwin maintainer.

I strongly recommend reviewing this one commit‐by‐commit. See the commit messages for much more detail and for things I’m still uncertain about. I’ve been running this on my own system for a while now, but it could definitely use a staged roll‐out before we actually hit the merge button. We should also probably also reach out to authors of third‐party modules that will be affected once it’s mostly baked, though at least anything that breaks should mostly break loudly. (Adding text to our existing activationScripts.{checks,userDefaults,userLaunchd,homebrew}.text definitions is an exception – those will run as root now. But I can’t think of a particularly graceful way to handle that case, and anyway it’s not exactly something we fully support in the first place.)

Closes: #96

modules/system/primary-user.nix

spikespaz

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 understand the motive here, but are you sure it's not better to make more breaking changes in one go? I'm worried that going through another great migration would agitate some.

emilazy · 2025-02-18T15:37:55Z

I previously thought that too – that we should figure out the correct interfaces and write good migration documentation and tools and get all the breaking changes over with in one go – but the end result was that this work stalled out for years because there’s a lot of API design and implementation work to get things to a good state: we need to decide which things should be global or per‐user; we need to decide what should stay in nix-darwin and what should be deduplicated with Home Manager; for things like our system.defaults options, they’re currently not fully declarative in the way that Nix‐managed options should be, so if we’re breaking everyone’s configuration then we ought to make that important breaking change at the same time; and so on.

If we tried to do it all at once, this work would have spent even longer in development hell and be unreviewably big. For the longest time i wasn’t sure how to resolve that, but after discussing on Matrix I realized that introducing a system.primaryUser option, though strange from an interface design perspective, would allow us to minimize the breaking changes in the first phase: the only required change for the vast majority of users should be having to set system.primaryUser = "username"; in their configuration, which I think is an acceptable level of fuss for the improvement in internal architecture and coherent model it gives us, and allows people who want a truly user‐agnostic system manager to opt for that world now at the expense of reduced functionality. That takes the pressure off any major interface renovations and lets us work on them independently and batch them up as we see fit.

In the case of Homebrew, homebrew.user defaults to the primary user, so it’s purely a bonus for people who want to use Homebrew without setting system.primaryUser (or to use a different user entirely for Homebrew, I suppose).

hraban · 2025-03-03T13:33:19Z

Most of the system.defaults stuff should really move to home-manager anyway, as you said. It's a natural fit and it works well.

mirkolenz · 2025-03-03T16:28:47Z

I've been running this branch on my machine for the past week and had zero issues with it, thanks for these great improvements!

Fixes #60. Ref: - nix-darwin/nix-darwin#1341 - nix-darwin/nix-darwin#96

khaneliman · 2025-03-08T23:01:11Z

Been running this for a few days since I got back from vacation. Noticing issues with nix store on reboots, haven't pinned down what's going on atm. Not sure if I need to do something different, I just tested copying the branch and rebasing it on master. Running my normal rebuild mentions the sudo requirement, doing a sudo rebuild mentions I need a primary user, adding a primary user and then it rebuilds.

Just noting symptoms:

Dock icons missing that point to nix store
Firefox error about profile missing on boot (assuming same issue with dock about files being available on login)
launchd services in a retry backoff until i unload them and load them manually

2025-03-08 14:57:39.712350 <Warning> Could not find and/or execute program specified by service: 2: No such file or directory: /nix/store/fa3jr2wxgbiyk37h0imzhhj13c3p6gqv-yabai-7.1.10/bin/yabai
2025-03-08 14:57:39.712351 <Error> Service could not initialize: access(/nix/store/fa3jr2wxgbiyk37h0imzhhj13c3p6gqv-yabai-7.1.10/bin/yabai, X_OK) failed with errno 2 - No such file or directory, error 0x6f - Invalid or missing Program/ProgramArguments
2025-03-08 14:57:39.712352 <Error> initialization failure: 24D70: xpcproxy + 36768 [1088][E4C3A3C3-0D57-3E4D-8388-880BC7F5F19E]: 0x6f
2025-03-08 14:57:39.712353 <Notice> Service setup event to handle failure and will not launch until it fires.
2025-03-08 14:57:39.712354 <Error> Missing executable detected. Job: 'org.nixos.yabai' Executable: '/nix/store/fa3jr2wxgbiyk37h0imzhhj13c3p6gqv-yabai-7.1.10/bin/yabai'

emilazy · 2025-03-10T19:42:15Z

That’s very confusing. I’m not sure how that could result from these changes. Are you sure you get the same result if you run the base commit that you rebased on top of? Were there any conflicts during the rebase that you had to resolve?

khaneliman · 2025-03-10T20:12:41Z

That’s very confusing. I’m not sure how that could result from these changes. Are you sure you get the same result if you run the base commit that you rebased on top of? Were there any conflicts during the rebase that you had to resolve?

Yeah, sorry... not a lot of information, I know... Probably can just disregard it for now... I'll try bisecting and see where it might have come from. Even switching back to master I get the behavior still.

WeetHet · 2025-03-11T07:19:14Z

2025-03-08 14:57:39.712350 <Warning> Could not find and/or execute program specified by service: 2: No such file or directory: /nix/store/fa3jr2wxgbiyk37h0imzhhj13c3p6gqv-yabai-7.1.10/bin/yabai
2025-03-08 14:57:39.712351 <Error> Service could not initialize: access(/nix/store/fa3jr2wxgbiyk37h0imzhhj13c3p6gqv-yabai-7.1.10/bin/yabai, X_OK) failed with errno 2 - No such file or directory, error 0x6f - Invalid or missing Program/ProgramArguments
2025-03-08 14:57:39.712352 <Error> initialization failure: 24D70: xpcproxy + 36768 [1088][E4C3A3C3-0D57-3E4D-8388-880BC7F5F19E]: 0x6f
2025-03-08 14:57:39.712353 <Notice> Service setup event to handle failure and will not launch until it fires.
2025-03-08 14:57:39.712354 <Error> Missing executable detected. Job: 'org.nixos.yabai' Executable: '/nix/store/fa3jr2wxgbiyk37h0imzhhj13c3p6gqv-yabai-7.1.10/bin/yabai'

This is the exact reason nix-darwin uses /bin/wait4path. You can replace the binary inside of the service with a /bin/sh that calls wait4path with the yabai executable or try copying it outside of the store

khaneliman · 2025-03-11T13:51:43Z

2025-03-08 14:57:39.712350 <Warning> Could not find and/or execute program specified by service: 2: No such file or directory: /nix/store/fa3jr2wxgbiyk37h0imzhhj13c3p6gqv-yabai-7.1.10/bin/yabai
2025-03-08 14:57:39.712351 <Error> Service could not initialize: access(/nix/store/fa3jr2wxgbiyk37h0imzhhj13c3p6gqv-yabai-7.1.10/bin/yabai, X_OK) failed with errno 2 - No such file or directory, error 0x6f - Invalid or missing Program/ProgramArguments
2025-03-08 14:57:39.712352 <Error> initialization failure: 24D70: xpcproxy + 36768 [1088][E4C3A3C3-0D57-3E4D-8388-880BC7F5F19E]: 0x6f
2025-03-08 14:57:39.712353 <Notice> Service setup event to handle failure and will not launch until it fires.
2025-03-08 14:57:39.712354 <Error> Missing executable detected. Job: 'org.nixos.yabai' Executable: '/nix/store/fa3jr2wxgbiyk37h0imzhhj13c3p6gqv-yabai-7.1.10/bin/yabai'

This is the exact reason nix-darwin uses /bin/wait4path. You can replace the binary inside of the service with a /bin/sh that calls wait4path with the yabai executable or try copying it outside of the store

This is using the nix-darwin service. I do see that it doesn't contain wait4path like it used to. Thanks for reminding me about that. I'll see why it's missing now.

Samasaur1

It's finally happening! This looks really good in general — left a couple notes and questions but I think many of these changes may just have to be breaking.

tests/homebrew.nix

Samasaur1 · 2025-02-16T08:30:56Z

tests/system-defaults-write.nix

@@ -1,6 +1,8 @@
 { config, pkgs, lib, ... }:

 {
+  system.primaryUser = "test-defaults-user";


same concern about the user needing to exist

(Same answer.)

Samasaur1 · 2025-03-11T18:16:45Z

modules/system/launchd.nix

      # Set up user launchd services in ~/Library/LaunchAgents
      echo "setting up user launchd services..."

-      ${concatStringsSep "\n" (launchdVariables config.launchd.user.envVariables)}
+      ${concatStringsSep "\n" (launchdVariables "sudo -u ${user} --" config.launchd.user.envVariables)}


Using sudo -u ${user} does feel like one of those weird corner-cases where launchd will just fail to do what you expect it to — I like the idea of using launchctl asuser, especially considering it hasn't been replaced with anything else (other than using a domain target for the given user), but I do notice the man page says

This executes the given command in as similar an execution context as possible to that of the target user's bootstrap. Adopted attributes include the Mach bootstrap namespace, exception server and security audit session. It does not modify the process' credentials (UID, GID, etc.) or adopt any user-specific environment variables. It affects only the Mach bootstrap context and directly- related attributes.

(emphasis mine). This might mean that the way to do it is

sudo -u ${user} -- launchctl asuser $(id -u ${user})

which is ugly but seems like it carries over more of the appropriate context.

That said, if this is working as-is in multi-user setups I'm also inclined to leave it as is until we swap to the new launchctl commands. My concern is mostly around activation for users who aren't graphically logged-in. This is already sometimes a pain point for me when I darwin-rebuild over SSH, and so I imagine that we may run into similar issues here if user A (logged in graphically) runs darwin-rebuild and the launchd activation doesn't work properly for user B (maybe not logged in, maybe logged in in a separate graphical session, etc.)

Right. I haven’t tested this extensively; if someone can confirm that it seems to work as‐is then I’d be inclined to just leave it until we start using the recommended commands rather than adding more deprecated ones. I’m certainly curious how this goes with actiavtion over SSH.

@mirkolenz @khaneliman and anyone else who's running this branch: any chance you manage any multi-user nix-darwin systems? Have you noticed any strangeness with launchd activation, especially if you've happened to run activations as one user while a different user is actively signed in?

Or activation over SSH

It's also occurring to me that even if this doesn't work perfectly, it should continue to work at least as well as the situation before this PR. I'd say that if anyone reports an issue with this, we can try and track it down, but otherwise we can just leave it as you have it here

All systems I tested this on are single-user only, sorry...

As in, because people will usually be doing sudo darwin-rebuild … as their primary user, and so the sudo sudo --user=primary-user will cancel out the UID stuff and the Mach bootstrap context will be inherited from their graphical session? I suppose so. But ideally this should work even if you set a different primary user, too, so it’d be good to know one way or another. I just haven’t had the time to set up a VM to test a separate admin user, or SSH activation, or whatever. (I tested all this on my development machine because I love danger.)

Samasaur1 · 2025-03-11T18:17:35Z

modules/system/defaults-write.nix

@@ -9,6 +9,10 @@ let
    "defaults write ${domain} '${key}' $'${strings.escape [ "'" ] (generators.toPlist { } value)}'";

  defaultsToList = domain: attrs: mapAttrsToList (writeDefault domain) (filterAttrs (n: v: v != null) attrs);
+  userDefaultsToList = domain: attrs: map
+    (cmd: "sudo --user=${escapeShellArg config.system.primaryUser} -- ${cmd}")


Is there a reason you use sudo -u ${user} for launchctl but sudo --user=${user} here?

No reason at all. I’ve moved to --user= across the board.

Samasaur1 · 2025-03-11T18:19:55Z

modules/environment/default.nix

+      config.nix.enable
+      && !config.nixpkgs.flake.setNixPath
+      && config.system.stateVersion < 6
+      && options.environment.darwinConfig.highestPrio == (mkOptionDefault {}).priority


I hate that I can't think of a better way to check that this option wasn't changed from the default

This is the only way I've done it, too.

Yeah it’s awful and I hate it. But I hate not giving good error messages when doing complicated migrations even more.

Samasaur1 · 2025-03-11T18:23:11Z

modules/system/primary-user.nix

+      default =
+        config.users.users.${config.system.primaryUser}.home or "/Users/${config.system.primaryUser}";
+    };


Will this break anything if config.system.primaryUser is set to null (the default)? If I'm reading it correctly, it's only an issue if primaryUserHome is read by something, in which case primaryUser needs to be set anyway, but I wonder what the error message would look like. Maybe it's caught by nix.nixPath requiring primaryUser to be set? Not sure that works for environment.darwinConfig though

It’ll be an evaluation error if anything depends on it. But, yes, that stuff should set system.requiresPrimaryUser (as environment.darwinConfig does) and therefore hopefully give a helpful error message before anything that uses it would get evaluated. "${null}" is also an error so I’m not sure allowing it to be null would improve anything. Maybe this could be a more descriptive throw in that case? But I haven’t triggered it so far in testing.

Maybe

lib.warnIf (config.system.primaryUser == null) "`system.primaryUser` is unset but `system.primaryUserHome` is being read" config.users.users.${config.system.primaryUser}.home or "/Users/${config.system.primaryUser}";

?

On the other hand, it seems like this problem will only be hit due to a future mistake on our part (reading primaryUserHome in an option without adding that option to requiresPrimaryUser), so we could just leave this as is.

Making it a throwIf might be a good idea, and seems pretty harmless. I’ll think about it. The main thing is that I wish we could make incorrect uses of config.system.primaryUser fail loudly in the same way, but that’s harder.

Samasaur1 · 2025-03-11T18:25:47Z

pkgs/darwin-uninstaller/configuration.nix

  system.activationScripts.postActivation.text = mkAfter ''
    nix-channel --remove darwin || true

+    ${optionalString (config.system.primaryUser != null) ''
+      sudo \
+        --user=${config.system.primaryUser} \


not shell escaping the primary user

Honestly anyone who tries to set a username that requires shell escaping has it coming. But, yeah, fixed.

Samasaur1 · 2025-03-11T18:45:12Z

modules/services/activate-system/default.nix

@@ -65,7 +65,7 @@ in
          ln -sfn /run/current-system /nix/var/nix/gcroots/current-system
        fi

-        ${config.system.activationScripts.etcChecks.text}
+        ${config.system.activationScripts.checks.text}


The one thing I am concerned about here is if checks has stuff that needs to be run in a graphical context. Based on a quick search through our in-tree checks it seems like this change would cause errors for the activation daemon from modules/users/default.nix in some cases, it might cause errors for our other checks, and might for out-of-tree checks if people were assuming that checks would only run in a graphical session.

The activation daemon only activates system configurations that were previously current. So in theory it should never be trying to delete users and so on. What other checks do you think might be problematic here?

Ah, good point. I don't have any problematic checks I can think of, and they should be read-only anyway, so I'm good with this.

Samasaur1 · 2025-03-11T18:46:24Z

modules/system/activation-scripts.nix

      ${cfg.activationScripts.checks.text}
+      ${cfg.activationScripts.createRun.text}


This is also a potential point where out-of-tree checks could break, if people assume that /run will already exist. I think this is still a worthwhile change to make, but worth pointing out.

We could put it before checks if this is considered a big problem; I just figured it’s best to change the system as little as possible if any checks are failing.

I think this is definitely an improvement that we should make, just noting the potential issue here in case we see it in the future.

Samasaur1

I think that covers everything I saw! Another pair of eyes certainly wouldn't hurt but this LGTM

retrry · 2025-03-17T08:11:57Z

Hey, I've just not long ago moved to flakes and don't have a lot of experience here. Could someone give me rough instructions how I would test it with flake setup? I would like to help 🙂 based on what I am seeing in the PR already started migrating away from services and config options which require primaryUser.

mirkolenz · 2025-03-17T08:33:46Z

You can test it by adding the following snippet to your flake:

inputs.nix-darwin = {
  url = "github:lnl7/nix-darwin/pull/1341/merge";
  inputs.nixpkgs.follows = "nixpkgs"; # if you want to lock it to the same rev as your main nixpkgs instance
};

retrry · 2025-03-17T09:38:51Z

So it is a bit strange for me with launch agents 🙂 I've had couple launch agents defined via launchd.user.agents. Those options require primaryUser set (these are only two options, which I've had left, which require primaryUser). I've tried two things:

Just remove those options and not set primaryUser. The problem is that those launchAgents do not get removed.
Set primaryUser, rebuild, remove launchd options, rebuild - those launch agents are still not removed.
Reverted to master config, rebuild, remove those options, rebuild - now they get removed.

Samasaur1 · 2025-03-18T05:28:31Z

3 sounds like expected behavior. 1, unfortunately, also sounds like expected behavior, since the code to handle removing those LaunchAgents has itself been removed. 2 is surprising to me though, unless the LaunchAgent plists are put at a different path?

System activation scripts shouldn’t (and soon won’t be able to) rely on `$HOME` being the primary user’s.

These can’t be relied upon in a post‐user‐activation world. Technically a breaking change, if anyone has their home directory outside of `/Users` or is using `root` for this, but, well, I did my best and these are legacy defaults anyway.

🎉 Closes: nix-darwin#96

(With some tweaks to handle `nix.enable` and order it at a more sensible position in the `$PATH`.) The installers actually install Nix into `root`’s profile for some reason, which means that the path’s prioritization backfires when the script runs as root and we’re managing the Nix installation. When running `darwin-rebuild` as a normal user, this wasn’t a problem. Maybe we should just have a check to make sure there’s no conflicting Nix in `root`’s profile – it seems pretty bad for `root` to get the wrong Nix – but it would trigger for almost everyone, which seems kind of annoying. I guess we could automatically remove it from `root`’s profile if it matches what’s in `/nix/var/nix/profiles/default`… This reverts commit 02232f7.

The `activate-system` daemon will now run all the checks, which seems like probably a good idea anyway?

The checks should no longer depend on `/run`, so this avoids modifying the system before they run.

Fixes #60. Ref: - nix-darwin/nix-darwin#1341 - nix-darwin/nix-darwin#96

retrry · 2025-04-05T16:04:18Z

@emilazy sorry for taking so long to get back, but you know - life 😄 But today I've tested it again and yeah, launch agents do not get removed for me in a specific case 🙁

My flow:

Update flake.nix
Run darwin-rebuild switch
Run sudo darwin-rebuild switch
Add launch agent and set primaryUser
Run `sudo darwin-rebuild switch -- agent gets added.
Comment out agent code
Run sudo darwin-rebuild switch
Agent is still there...

My launch agent is pretty simple:

  launchd.user.agents = {
    docker_host = {
      serviceConfig = {
        ProgramArguments = [
          "launchctl"
          "setenv"
          "DOCKER_HOST"
          "unix:///Users/${username}/.config/colima/default/docker.sock"
        ];
        RunAtLoad = true;
        KeepAlive = false;
      };
    };
  };

After testing more - I think the problem is when you fully remove launch agents. Then nothing is being run.

I've create two agents docker_host and docker_host_2. If I remove one - it gets removed. If I remove both - it doesn't get removed 🙂

Running sudo darwin-rebuild switch key log parts:
One removed, but at least 1 launch agent still exists:

setting up /etc...
setting up launchd services...
setting up user launchd services...
removing user service org.nixos.docker_host
reloading nix-daemon...

Both removed and no agents exist:

setting up /etc...
setting up launchd services...
reloading nix-daemon...

So it seems that if that config options is not defined - setting up user launchd services... just doesn't run at all.

I hope that helps 🤷

Fixes zhaofengli#60. Ref: - nix-darwin/nix-darwin#1341 - nix-darwin/nix-darwin#96

Enzime · 2025-04-10T08:45:14Z

Fixed the merge conflicts, please rebase later when you have a chance 👍

Enzime · 2025-04-12T18:14:38Z

modules/system/checks.nix

@@ -31,6 +31,18 @@ let
    fi
  '';

+  primaryUser = ''
+    primaryUser=${escapeShellArg config.system.primaryUser}


Suggested change

primaryUser=${escapeShellArg config.system.primaryUser}

primaryUser="${config.system.primaryUser}"

In /nix/store/726gp7jnx7blz46azrds8l28a5zqdqgg-darwin-system-25.05.0653ce2/activate line 63: primaryUser=admin ^---------^ SC2209 (warning): Use var=$(command) to assign output (or quote to assign string). For more information: https://www.shellcheck.net/wiki/SC2209 -- Use var=$(command) to assign outp...

This should still be escapeShellArg, right? If only for consistency's sake?

escapeShellArg will add some single quotes which will mess with the value of primaryUser I believe so best to leave it out here if we're manually quoting

Alternatively we could use escapeShellArgAlways:

nix-darwin/modules/services/github-runner/service.nix

Lines 105 to 108 in 43975d7

# https://github.com/NixOS/nixpkgs/pull/333744 introduced an inconsistency with different

# versions of nixpkgs. Use the old version of escapeShellArg to make sure that labels

# are always escaped to avoid https://www.shellcheck.net/wiki/SC2054

escapeShellArgAlways = string: "'${replaceStrings ["'"] ["'\\''"] (toString string)}'";

Could we also just do escapeShellArg and disable this warning? Although I don't know if that would be tangibly different from just doing what you suggested here.

Feels like the linter is wrong here because it doesn't know the value came from a proper escape function. my +1 on silencing the linter. For what that's worth :)

Enzime · 2025-04-15T16:56:49Z

modules/system/checks.nix

@@ -31,6 +31,18 @@ let
    fi
  '';

+  primaryUser = ''
+    primaryUser=${escapeShellArg config.system.primaryUser}
+    if ! id -- "$primaryUser" >/dev/null 2>&1; then


Suggested change

if ! id -- "$primaryUser" >/dev/null 2>&1; then

if ! id -- "$primaryUser" &>/dev/null; then

Minor nit

Enzime · 2025-04-17T16:06:49Z

modules/homebrew.nix

@@ -559,6 +559,17 @@ in
      This module also provides a few options for modifying how Homebrew commands behave when
      you manually invoke them, under [](#opt-homebrew.global)'';

+    user = mkOption {


Wonder if we should add an assertion/warning against setting this to root

Enzime · 2025-04-17T19:23:06Z

Slowly reviewing commit by commit I'll post my review feedback as I go so that it doesn't get stuck in limbo until I'm done reviewing the whole thing

Enzime · 2025-04-20T18:47:34Z

modules/users/default.nix

@@ -155,7 +155,7 @@ in
        homeDirectory=$(dscl . -read /Users/nobody NFSHomeDirectory)


The comment above this is no longer necessary 👍

Enzime · 2025-04-20T18:53:22Z

tests/networking-hostname.nix

@@ -9,6 +9,5 @@
    grep "scutil --set ComputerName 'EVE’s MacBook Pro'" ${config.out}/activate
    grep "scutil --set LocalHostName ${lib.escapeShellArg "EVE"}" ${config.out}/activate
    grep "scutil --set HostName ${lib.escapeShellArg "EVE"}" ${config.out}/activate
-    echo checking defaults write in ${config.out}/activate-user >&2


Minor nit: could be squashed into the previous commit

Enzime · 2025-04-20T18:57:51Z

README.md

@@ -186,13 +186,13 @@ The documentation is also available as manpages by running `man 5 configuration.
 To run the latest version of the uninstaller, you can run the following command:

 ```
-nix --extra-experimental-features "nix-command flakes" run nix-darwin#darwin-uninstaller
+sudo nix --extra-experimental-features "nix-command flakes" run nix-darwin#darwin-uninstaller


Not a blocker, but this might lead to some issues with system.primaryUser not being set

Enzime · 2025-04-20T19:04:16Z

modules/nix/nix-darwin.nix

@@ -5,6 +5,7 @@ let
    inherit (config.system) profile;
    inherit (config.environment) systemPath;
    nixPath = lib.optionalString config.nix.enable (lib.concatStringsSep ":" config.nix.nixPath);
+    nixPackage = if config.nix.enable then config.nix.package else null;


This commit can be dropped :)

Enzime

Apart from all my comments above, this PR looks good to me

I'm running successfully on 3 machines so far :)

Fixes #60. Ref: - nix-darwin/nix-darwin#1341 - nix-darwin/nix-darwin#96

emilazy requested a review from Enzime February 16, 2025 02:12

emilazy mentioned this pull request Feb 16, 2025

Multiple problems when setting up multiple macos users #554

Open

emilazy force-pushed the push-vuqkuqtwsoox branch from f2bd544 to 454a716 Compare February 16, 2025 16:30

spikespaz reviewed Feb 18, 2025

View reviewed changes

modules/system/primary-user.nix Show resolved Hide resolved

spikespaz reviewed Feb 18, 2025

View reviewed changes

emilazy force-pushed the push-vuqkuqtwsoox branch 2 times, most recently from 229a7c6 to a387b4b Compare February 20, 2025 02:31

emilazy mentioned this pull request Feb 21, 2025

darwin-rebuild: Don't prompt for sudo multiple times #1147

Open

Isolaryn mentioned this pull request Feb 22, 2025

Plan for removal of user activation. zhaofengli/nix-homebrew#60

Open

emilazy mentioned this pull request Feb 25, 2025

darwin -> darwin doesn't invoke user activation script serokell/deploy-rs#259

Open

zhaofengli added a commit to zhaofengli/nix-homebrew that referenced this pull request Mar 3, 2025

Support nix-darwin system-wide activation

96b4688

Fixes #60. Ref: - nix-darwin/nix-darwin#1341 - nix-darwin/nix-darwin#96

zhaofengli mentioned this pull request Mar 3, 2025

Support nix-darwin system-wide activation zhaofengli/nix-homebrew#64

Open

isabelroses mentioned this pull request Mar 6, 2025

darwin: support new system activation nix-community/nh#233

Open

Samasaur1 reviewed Mar 11, 2025

View reviewed changes

emilazy force-pushed the push-vuqkuqtwsoox branch from a387b4b to 0d9daef Compare March 12, 2025 00:48

Samasaur1 approved these changes Mar 12, 2025

View reviewed changes

khaneliman mentioned this pull request Mar 18, 2025

darwin.rs: handle new root only activation nix-community/nh#238

Draft

primary-user: init

e0c3c3e

emilazy added 12 commits March 23, 2025 11:55

applications: use system.primaryUser for the legacy path

dee253c

System activation scripts shouldn’t (and soon won’t be able to) rely on `$HOME` being the primary user’s.

users: refuse to delete the primary user

52026cf

activation-scripts: get rid of user activation

c8660d0

🎉 Closes: nix-darwin#96

tests: remove stray activate-user references

2c4fc49

darwin-rebuild: require running as root

1008b7d

{activation-scripts,activate-system}: purify environment again

ca0c46a

checks: make nixPath check more helpful

b317dbe

etc: merge etcChecks into checks

26c02d8

The `activate-system` daemon will now run all the checks, which seems like probably a good idea anyway?

activation-scripts: move createRun after checks

b58d98d

The checks should no longer depend on `/run`, so this avoids modifying the system before they run.

changelog: document user activation removal

fcaa984

emilazy force-pushed the push-vuqkuqtwsoox branch from b569b0f to fcaa984 Compare March 23, 2025 11:56

zhaofengli added a commit to zhaofengli/nix-homebrew that referenced this pull request Mar 24, 2025

Support nix-darwin system-wide activation

4641185

Fixes #60. Ref: - nix-darwin/nix-darwin#1341 - nix-darwin/nix-darwin#96

romaingrx mentioned this pull request Mar 27, 2025

Update nix-darwin config for multi-user support romaingrx/dotfiles#2

Open

Enzime mentioned this pull request Mar 30, 2025

nix-tools: re‐add nixPackage #1410

Merged

isabelroses pushed a commit to isabelroses/nix-homebrew that referenced this pull request Apr 9, 2025

Support nix-darwin system-wide activation

e3c8403

Fixes zhaofengli#60. Ref: - nix-darwin/nix-darwin#1341 - nix-darwin/nix-darwin#96

Merge remote-tracking branch 'upstream' into push-vuqkuqtwsoox

640899e

zowoq mentioned this pull request Apr 12, 2025

runNixDarwin: add sudo activation hercules-ci/hercules-ci-effects#188

Draft

3 tasks

Enzime requested changes Apr 12, 2025

View reviewed changes

Enzime reviewed Apr 17, 2025

View reviewed changes

Enzime reviewed Apr 20, 2025

View reviewed changes

Enzime approved these changes Apr 20, 2025

View reviewed changes

zhaofengli added a commit to zhaofengli/nix-homebrew that referenced this pull request May 5, 2025

Support nix-darwin system-wide activation

1a9c66b

Fixes #60. Ref: - nix-darwin/nix-darwin#1341 - nix-darwin/nix-darwin#96

		${cfg.activationScripts.checks.text}
		${cfg.activationScripts.createRun.text}

	primaryUser=${escapeShellArg config.system.primaryUser}
	primaryUser="${config.system.primaryUser}"

	# https://github.com/NixOS/nixpkgs/pull/333744 introduced an inconsistency with different
	# versions of nixpkgs. Use the old version of escapeShellArg to make sure that labels
	# are always escaped to avoid https://www.shellcheck.net/wiki/SC2054
	escapeShellArgAlways = string: "'${replaceStrings ["'"] ["'\\''"] (toString string)}'";

	if ! id -- "$primaryUser" >/dev/null 2>&1; then
	if ! id -- "$primaryUser" &>/dev/null; then

		@@ -155,7 +155,7 @@ in
		homeDirectory=$(dscl . -read /Users/nobody NFSHomeDirectory)

The Plan, phase 1 #1341

Are you sure you want to change the base?

The Plan, phase 1 #1341

Conversation

emilazy commented Feb 16, 2025

spikespaz left a comment

Choose a reason for hiding this comment

emilazy commented Feb 18, 2025

hraban commented Mar 3, 2025

mirkolenz commented Mar 3, 2025

khaneliman commented Mar 8, 2025

emilazy commented Mar 10, 2025

khaneliman commented Mar 10, 2025 • edited Loading

WeetHet commented Mar 11, 2025 • edited Loading

khaneliman commented Mar 11, 2025

Samasaur1 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Samasaur1 left a comment

Choose a reason for hiding this comment

retrry commented Mar 17, 2025

mirkolenz commented Mar 17, 2025

retrry commented Mar 17, 2025

Samasaur1 commented Mar 18, 2025

retrry commented Apr 5, 2025 • edited Loading

Enzime commented Apr 10, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Enzime commented Apr 17, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Enzime left a comment

Choose a reason for hiding this comment

khaneliman commented Mar 10, 2025 •

edited

Loading

WeetHet commented Mar 11, 2025 •

edited

Loading

retrry commented Apr 5, 2025 •

edited

Loading