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