how nutty would it be to have a Nix installer attempt to get nix-daemon.sh's environment changes handled by an init system/session manager, if available, rather than plugging directly into a shell?

Fish users who are Nix novices (and maybe also Unix novices) have struggled getting their shell to 'nixify' properly forever. I've tried to work on it, and helped get something usable going for NixOS which is now also used in Nix-Darwin. But people still struggle, many years later, and other fun new shells (Elvish, Nushell, PowerShell, Xonsh, idk) face similar problems with Nix's POSIX initialization scripts

I think we could easily have the Nix stuff happen before the user session starts with systemd on Linux and launchd on macOS

how nutty would it be to have a Nix installer attempt to get nix-daemon.sh's environment changes handled by an init system/session manager, if available, rather than plugging directly into a shell?

Fish users who are Nix novices (and maybe also Unix novices) have struggled getting their shell to 'nixify' properly forever. I've tried to work on it, and helped get something usable going for NixOS which is now also used in Nix-Darwin. But people still struggle, many years later, on foreign Linux and macOS. Other fun new shells (Elvish, Nushell, PowerShell, Xonsh, idk) face similar problems with Nix's POSIX initialization scripts

I think we could easily have the Nix stuff happen before the user session starts with systemd on Linux and launchd on macOS

Have you tried setting this up with launchctl (and on what macOS version?)

It sounds like (thanks to cole-h for finding my own past comments about this :)) we are hemmed in on the global environment point by macOS these days, see for example:

• https://github.com/canonical/multipass/issues/2417#issuecomment-1553437799
• https://github.com/cachix/install-nix-action/issues/183#issuecomment-1595055643

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?

I do, but I don't think that's quite it, since I actually do get that error on my system (macOS 14.4.1)

This works:

• setting per-user session variables interactively with launchctl setenv via LaunchAgents as my user (works immediately; close and relaunch your terminal emulator and it'll pick up the variables)
• settting per-user session variables interactively with launchctl setenv in LaunchAgents that run as root
• setting global session variables with launchctl setenv in LaunchAgents that run as root (takes effect with next session)

but this doesn't work:

• interactively using launchctl setenv as root, which yields the message Could not set environment: 150: Operation not permitted while System Integrity Protection is engaged

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?)