2 ms·

> if any combination of the technical changes here are sufficient to multiply the number of people willing and able to touch the installer, I'll make my peace w

by pxc 4y ago

> if any combination of the technical changes here are sufficient to multiply the number of people willing and able to touch the installer, I'll make my peace with the tradeoffs. Do you feel similarly about the Nix setup scripts that the installer works to ensure are sourced by user shells? I'd kinda love to see those go and be replaced by a little program that sets up a Nix environment and then launches a shell for you, kinda like the `login` program. The shell-based approach has made supporting incompatible shells kinda nasty and clunky.

grhmc 4y ago
I certainly feel that way.
abathur 4y ago
I have managed to avoid fiddling with the init hook scripts themselves, so I hadn't actually thought about this specific idea. IDK if my thoughts will be productive/incisive. I've definitely felt like the Nth-shell situation is untenable and that we'll either need to abstract a definition to generate the hooks from or find some other ~general/universal solution. I like the way this suggestion sounds with respect to getting out of that maintainability problem, but I'm not sure if it'll work quite right? Here's one crappy rabbit-hole we've gone down: Since macOS changed its default shell to zsh, they've been overwriting /etc/zshrc with every update (this evicts Nix's hook, confuses/scares people, and makes them try to reinstall; note that they aren't using the Relocated Items treatment we'd expect from how they do this with most stuff in /etc/ including /etc/bashrc while it was still the default shell). An enterprising zsh user PRed a fix that moves the hook to /etc/zshenv. macOS doesn't ship /etc/zshenv, so they don't overwrite it on update. It seems to work at a blush, but Nix and everything you install with Nix ends up at the end of your PATH instead of the beginning, so everything that depends on a PATH lookup will keep using your system utilities. Why? IIRC because the /etc/zshprofile macOS ships will do "eval `/usr/libexec/path_helper -s`", and path_helper will add things from /etc/paths and /etc/paths.d to the left of the existing PATH. I suspect if we inject a binary or even a script to preconfigure this environment, the call to path_helper in the zsh init process is still going to leave everything we added at the end of the PATH. We could in theory add an /etc/paths.d/nix, but path_helper appends this after everything in /etc/paths, so it has the same problem. We could stick our Nix-related directories at the top of /etc/paths, but macOS does ship this file so we have no reason to have faith that macOS updates don't overwrite it or won't start doing so at some point. (We might also be able to move this to /etc/zshenv and also define a `/usr/libexec/path_helper(){ ... }` function that behaves like WE want--but that could obviously have downstream effects on other code in user profile/init scripts that uses path_helper. No clue if this is common.)

by pxc 4y ago

grhmc 4y ago

I certainly feel that way.

abathur 4y ago

I have managed to avoid fiddling with the init hook scripts themselves, so I hadn't actually thought about this specific idea. IDK if my thoughts will be productive/incisive. I've definitely felt like the Nth-shell situation is untenable and that we'll either need to abstract a definition to generate the hooks from or find some other ~general/universal solution. I like the way this suggestion sounds with respect to getting out of that maintainability problem, but I'm not sure if it'll work quite right? Here's one crappy rabbit-hole we've gone down: Since macOS changed its default shell to zsh, they've been overwriting /etc/zshrc with every update (this evicts Nix's hook, confuses/scares people, and makes them try to reinstall; note that they aren't using the Relocated Items treatment we'd expect from how they do this with most stuff in /etc/ including /etc/bashrc while it was still the default shell). An enterprising zsh user PRed a fix that moves the hook to /etc/zshenv. macOS doesn't ship /etc/zshenv, so they don't overwrite it on update. It seems to work at a blush, but Nix and everything you install with Nix ends up at the end of your PATH instead of the beginning, so everything that depends on a PATH lookup will keep using your system utilities. Why? IIRC because the /etc/zshprofile macOS ships will do "eval `/usr/libexec/path_helper -s`", and path_helper will add things from /etc/paths and /etc/paths.d to the left of the existing PATH. I suspect if we inject a binary or even a script to preconfigure this environment, the call to path_helper in the zsh init process is still going to leave everything we added at the end of the PATH. We could in theory add an /etc/paths.d/nix, but path_helper appends this after everything in /etc/paths, so it has the same problem. We could stick our Nix-related directories at the top of /etc/paths, but macOS does ship this file so we have no reason to have faith that macOS updates don't overwrite it or won't start doing so at some point. (We might also be able to move this to /etc/zshenv and also define a `/usr/libexec/path_helper(){ ... }` function that behaves like WE want--but that could obviously have downstream effects on other code in user profile/init scripts that uses path_helper. No clue if this is common.)