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:

@abathur:matrix.orgI found the PR, my memory was just flipped re: who submitted and who was present on it lol: https://github.com/NixOS/nix/pull/11009

BTW, is there some channel for reporting installer experiences? Is that a useful thing to do? I installed using the graphical installer; some issues I saw:

• (I'd assume this must be known) The keyboard layout selection did nothing
• It seemed to support replacing a logical volume in an LVM volume group, but I only ever got it to fail with an error or more often segfault

I installed using the graphical installer; some issues I saw:

• (I'd assume this must be known) The keyboard layout selection did nothing
• It seemed to support replacing a logical volume in an LVM volume group, but I only ever got it to fail with an error or more often segfault