I've been having Nix-Darwin generate the LaunchAgents I've been using to test. Here's what they look like, this example being the per-user one:

  launchd.user.agents.setenv.serviceConfig = {
    LimitLoadToSessionType = "Aqua";
    ProgramArguments = [
      "/bin/sh"
      "-pc"
      ''launchctl setenv FOO bar''
    ];
    RunAtLoad = true;
  };

In reply to @pxc:matrix.org
based on my testing I might venture a guess that what the SIP protection protects against is one user using elevated privileges to change the environment variable of another user's session in real-time, because those global LaunchAgents only affect new sessions

but I'm not totally convinced of my own guess

I guess one way to test this hypothesis would be to disable SIP and see if an interactive sudo setenv immediately changes my environment, too

and maybe also if logging in as a different user, elevating up to root, and then using sudo -u <other_user> launchctl setenv does anything

In reply to @abathur:matrix.org
can you confirm whether doing it interactively as non-root outside of a launchagent works?

In reply to @abathur:matrix.org
but if you've got it working on a newer macOS, perhaps they caused trouble for someone important and had to back off from the change?

it does look like using LaunchAgents to call launchtl setenv via /bin/sh is (or used to be?) a somewhat common/known pattern, if not a super popular one:

https://github.com/search?q=path%3A*.plist%20%22launchctl%20setenv%22&type=code

zooming out, speaking only for myself, and using lots of weasel words:

I can at least tentatively agree that being able to do everything we need via the init system would be a win as long as it doesn't break in other contexts and it doesn't end up fracturing the install base in a way that makes it much harder to help people troubleshoot installs.

Probably not exhaustive and I'm not trying to reason very thoroughly about them, but a few things that I could imagine shifting around:

• other non-nix daemons/agents/applications that haven't been getting tested by having our mods in their environment (for example, something that assumes default apple-shipped tools on the PATH and now they're getting GNU ones)
• at least with zsh, a problem that's come up with most of the workarounds we've tried here is that the default shell profiles run /usr/libexec/path_helper and hard-set PATH to whatever its opinion was--and this will shift our stuff down-PATH and keep anything Nix-installed from shadowing the system utils (some people want the system utils to be first, but I suspect most people want the nix-installed stuff to win); it isn't entirely on-topic, but off the top of my head https://github.com/NixOS/nix/pull/9243 probably documents a fair amount of that context
• Our shell profiles might be getting run in some contexts that are otherwise clearing all or part of their inherited environment, in which case moving up to the init layer might leave those without envs they have been running with
• race conditions? (probably just for other daemons? perhaps restoring/auto-opening apps? maybe a non-issue? not thinking that deeply)
• kinda doubt this is the case, but anything that actually diverges between shell implementations in a mutually-exclusive way? (at least, in a way we can't abstract around?)

As far as any risk of complicating the install-base, I'll just focus first on the fact that we'd still want to support non-systemd daemon installs (and that'll probably become increasingly true since I know some people have been working on improving our BSD-friendliness).

So I guess my next question is whether this can work beyond macOS and systemd? (shooting from the hip, I am a little leery of an outcome that looks like: we still end up having to maintain N daemon shell profiles for every shell someone would like to see supported and we also gain N separate processes for different init systems?)

In reply to @abathur:matrix.org

zooming out, speaking only for myself, and using lots of weasel words:

I can at least tentatively agree that being able to do everything we need via the init system would be a win as long as it doesn't break in other contexts and it doesn't end up fracturing the install base in a way that makes it much harder to help people troubleshoot installs.

Probably not exhaustive and I'm not trying to reason very thoroughly about them, but a few things that I could imagine shifting around:

• other non-nix daemons/agents/applications that haven't been getting tested by having our mods in their environment (for example, something that assumes default apple-shipped tools on the PATH and now they're getting GNU ones)
• at least with zsh, a problem that's come up with most of the workarounds we've tried here is that the default shell profiles run /usr/libexec/path_helper and hard-set PATH to whatever its opinion was--and this will shift our stuff down-PATH and keep anything Nix-installed from shadowing the system utils (some people want the system utils to be first, but I suspect most people want the nix-installed stuff to win); it isn't entirely on-topic, but off the top of my head https://github.com/NixOS/nix/pull/9243 probably documents a fair amount of that context
• Our shell profiles might be getting run in some contexts that are otherwise clearing all or part of their inherited environment, in which case moving up to the init layer might leave those without envs they have been running with
• race conditions? (probably just for other daemons? perhaps restoring/auto-opening apps? maybe a non-issue? not thinking that deeply)
• kinda doubt this is the case, but anything that actually diverges between shell implementations in a mutually-exclusive way? (at least, in a way we can't abstract around?)

As far as any risk of complicating the install-base, I'll just focus first on the fact that we'd still want to support non-systemd daemon installs (and that'll probably become increasingly true since I know some people have been working on improving our BSD-friendliness).

So I guess my next question is whether this can work beyond macOS and systemd? (shooting from the hip, I am a little leery of an outcome that looks like: we still end up having to maintain N daemon shell profiles for every shell someone would like to see supported and we also gain N separate processes for different init systems?)

at least with zsh, a problem that's come up with most of the workarounds we've tried here is that the default shell profiles run /usr/libexec/path_helper and hard-set PATH to whatever its opinion was--and this will shift our stuff down-PATH and keep anything Nix-installed from shadowing the system utils (some people want the system utils to be first, but I suspect most people want the nix-installed stuff to win); it isn't entirely on-topic, but off the top of my head https://github.com/NixOS/nix/pull/9243 probably documents a fair amount of that context

this is something important to me and yes, path_helpers has made a bit of a mess of things, incl. for Fish with Nix-Darwin, because by going out of our way to make sure the Nix stuff is sourced early, we also now ensure that it is overridden by whatever is in paths_helper.d. (Years ago, Fish did not consult the path 'helpers', now it does just after where we've injected nixification for it in nixpkgs' fish)

I see this as a related concern that I'm also directly interested in helping address

In reply to @abathur:matrix.org
On the latter point I'll also disclaim that I'm neither a gatekeeper nor is it a "no" from me even if I were. Just a concern. A big reliability boost is probably worth a small complexity boost, a big reliability boost might save more support effort than we lose to divergent install types, etc.

In reply to @abathur:matrix.org

zooming out, speaking only for myself, and using lots of weasel words:

I can at least tentatively agree that being able to do everything we need via the init system would be a win as long as it doesn't break in other contexts and it doesn't end up fracturing the install base in a way that makes it much harder to help people troubleshoot installs.

Probably not exhaustive and I'm not trying to reason very thoroughly about them, but a few things that I could imagine shifting around:

• other non-nix daemons/agents/applications that haven't been getting tested by having our mods in their environment (for example, something that assumes default apple-shipped tools on the PATH and now they're getting GNU ones)
• at least with zsh, a problem that's come up with most of the workarounds we've tried here is that the default shell profiles run /usr/libexec/path_helper and hard-set PATH to whatever its opinion was--and this will shift our stuff down-PATH and keep anything Nix-installed from shadowing the system utils (some people want the system utils to be first, but I suspect most people want the nix-installed stuff to win); it isn't entirely on-topic, but off the top of my head https://github.com/NixOS/nix/pull/9243 probably documents a fair amount of that context
• Our shell profiles might be getting run in some contexts that are otherwise clearing all or part of their inherited environment, in which case moving up to the init layer might leave those without envs they have been running with
• race conditions? (probably just for other daemons? perhaps restoring/auto-opening apps? maybe a non-issue? not thinking that deeply)
• kinda doubt this is the case, but anything that actually diverges between shell implementations in a mutually-exclusive way? (at least, in a way we can't abstract around?)

As far as any risk of complicating the install-base, I'll just focus first on the fact that we'd still want to support non-systemd daemon installs (and that'll probably become increasingly true since I know some people have been working on improving our BSD-friendliness).

So I guess my next question is whether this can work beyond macOS and systemd? (shooting from the hip, I am a little leery of an outcome that looks like: we still end up having to maintain N daemon shell profiles for every shell someone would like to see supported and we also gain N separate processes for different init systems?)

race conditions? (probably just for other daemons? perhaps restoring/auto-opening apps? maybe a non-issue? not thinking that deeply)

yes, I think race conditions are possible. One example that does things in a way that evinces this possibility is this AppleScript implementation of a GUI ssh-askpass for macOS. They restart the built-in SSH agent after setting their env vars because if their thing runs after it, those vars won't get picked up by the agent: