Oops!

/nix/store/6f429zrnlkpc8iymsci18w7dgh5km1vl-fish-2.6.0/share/fish/__nix_preinit_env.fish (line 15):
a
^
from sourcing file /nix/store/6f429zrnlkpc8iymsci18w7dgh5km1vl-fish-2.6.0/share/fish/__nix_preinit_env.fish
	called on line 9 of file /nix/store/6f429zrnlkpc8iymsci18w7dgh5km1vl-fish-2.6.0/share/fish/__fish_build_paths.fish

from sourcing file /nix/store/6f429zrnlkpc8iymsci18w7dgh5km1vl-fish-2.6.0/share/fish/__fish_build_paths.fish
	called on line 87 of file /nix/store/6f429zrnlkpc8iymsci18w7dgh5km1vl-fish-2.6.0/share/fish/config.fish

from sourcing file /nix/store/6f429zrnlkpc8iymsci18w7dgh5km1vl-fish-2.6.0/share/fish/config.fish
	called during startup

/nix/store/ab2iwb8ks5day43sw0580hdf54nfa4pv-bash-4.4-p12/bin/bash: @NIX_STORE/../var/nix/profiles/default/etc/profile.d/nix-daemon.sh: No such file or directory
Welcome to fish, the friendly interactive shell
Type help for instructions on how to use fish

With the following patch applied:

diff --git a/pkgs/shells/fish/default.nix b/pkgs/shells/fish/default.nix
index 39235f96d6..55b6d67af7 100644
--- a/pkgs/shells/fish/default.nix
+++ b/pkgs/shells/fish/default.nix
@@ -59,7 +59,7 @@ let
       else
         set -l common_prefix @NIX_STORE/../var/nix/profiles/default/etc/profile.d
         set -l script_selection nix.sh
-a
+
         string match -q (${coreutils}/bin/uname) Darwin
         # Use `set -U nix_on_darwin_no_daemon` to tell Fish to use the single-user mode script instead
         and not set -q nix_on_darwin_no_daemon

... I get:

/nix/store/ab2iwb8ks5day43sw0580hdf54nfa4pv-bash-4.4-p12/bin/bash: @NIX_STORE/../var/nix/profiles/default/etc/profile.d/nix-daemon.sh: No such file or directory

This patch gets things running smoothly for me:

diff --git a/pkgs/shells/fish/default.nix b/pkgs/shells/fish/default.nix
index 39235f96d6..30362d7e08 100644
--- a/pkgs/shells/fish/default.nix
+++ b/pkgs/shells/fish/default.nix
@@ -57,9 +57,9 @@ let
       if test -f /etc/nix/support/set-environment.sh
         set nix_env_setup /etc/nix/support/set-environment.sh
       else
-        set -l common_prefix @NIX_STORE/../var/nix/profiles/default/etc/profile.d
+        set -l common_prefix @NIX_STORE@/../var/nix/profiles/default/etc/profile.d
         set -l script_selection nix.sh
-a
+
         string match -q (${coreutils}/bin/uname) Darwin
         # Use `set -U nix_on_darwin_no_daemon` to tell Fish to use the single-user mode script instead
         and not set -q nix_on_darwin_no_daemon

urgh yeah that's a typo, sorry.

If it's reaching that part of the code, it's not using your nix-darwin config, though. The changes I described to nix-darwin will make that /etc/nix/support/set-environment.sh file appear, which is how the system I'm typing from is currently configured.

The bright side is that you just inadvertently tested the non-nix-darwin behavior! <3

Actually it looks like my $PATH is not getting set correctly.

I apologize for my sloppiness; I wrote this when I couldn't sleep at 2am last night and I kinda cleaned it up hastily this morning before work. Thanks for helping me test. :-D

@yurrriq is that with the set-environment.sh file present? I just rebuilt Fish after finding the typos you identified and manually mangled the /etc/nix/support/set-environment.sh link so that it would revert to the non-nix-darwin behavior, and everything worked fine.

Everything continues to work when it's using nix-darwin.

Did you remember to rebase the nix-darwin from Colin's PR against current? Those setEnvironment changes need to be in place; the existing state of the PR isn't enough.

That part is fixed now.

I'm still having $PATH issues, but with these checkouts together, my system works well:

• yurrriq@2670335 (8696c06 rebased on d26f8b5)
• nix-hackers/nix-darwin@0ea82db
• yurrriq/dotfiles@f266cfe

Suggestion: Change "completely erase" to "reset," since we aren't running set -e below. (I think this comment might have been copied over from the nix-darwin module?)

So replying to any of these via email from my phone was a mistake. But yeah, erasing it in case it is empty may be unnecessary and at any rate the language of complete erasure is no longer accurate.

Question: Is it correct to use -x here? I still feel uncertain about when we want to avoid duplicates vs. start a new clean environment.

Yes. Without this, new shells can't inherit any environment changes, for example, to PATH-- ever. This is because all the Nix initialization scripts set it outright instead of basing it on the existing PATH. Lacking this check breaks impure nix-shell environments, among other things, and set -gx is equivalent to the export as it is used in similar checks our scripts (in NixOS) for other shells.

Additionally, if you go a few lines up, you'll see that the __fish_nix_env_preinit_sourced variable is not even read for login shells. So to ensure that you get a clean environment, you can use fish -l and you're guaranteed to get one. :-)

I wrote this this way because at the time it felt like the easiest way to test the behavior that I want, but this is dumb because we already know at build time whether this Fish will run on Darwin or not. This should just be handled with some conditional in the Nix expression itself so that the correct behavior gets in-lined for Darwin and for other platforms.

Is an environment variable the right place to configure this?

How can we discern whether Nix should be using a daemon at this point in the configuration? Ordinarily, the Nix user chooses whether to use a daemon or not by modifying their shell config to source one script or the other. They can't modify the config that gets rolled into fish inside the Nix store.

This seems like a pretty natural solution to me. Do you think we should read from a file instead?

If that's how it happens normally that's fine—I just wanted to make sure it was the normal place to do it. The only other option I was thinking was reading from /etc/nix/nix.conf but I don't think that actually has info about whether or not a daemon is used.

@therealpxc Sorry, I'm not really qualified to review your changes: I updated the fish package a few time but I only have a vague idea of how the environment initializing works.

I'm a bit confused because I have never had the issue described in #18946.
For what is worth I'm ok for improving the situation for non-NixOs users.

@rnhmjoj The issue is something which can occur if sourcing the Nix setup script happens redundantly or too late in shell initialization. It can be tricky to get right, but this PR uses the same logic as NixOS, which works by setting up the Nix environment before Fish uses any config.

@cbarrett there actually is some config that goes in /etc/nix/nix.conf that we might be able to use. I know nix-build-users is normally unset for single-user mode, for example.

This duplication is maybe worth fixing now, maybe something to keep an eye on for later. 🤷‍♂️

Maybe the various shells should have a variable in common they use for this. But that's an issue that involves other shells and other parts of Nixpkgs. I think we can set it aside.

When these lines were essentially part of the NixOS module, I checked these variables for the same reason that the NixOS module does: we don't want to clobber configuration made elsewhere in NixOS or redundantly source things that have already been sourced from other shells.

But here, it's only used for the basic set-environment.sh script, which doesn't really include any user configuration. And on non-NixOS, those variables might never be set anyway. Here, maybe it makes more sense to just check NIX_PROFILES.

Yup yup. I've logged a separate issue about cleaning this up. #31322

I’m not 100% sure ../var/nix does always hold here.

Any ideas on when it wouldn't? (I would love a more robust way of doing this if anyone can think of one.)

Even more interesting: there is no /default/etc/profile.d on my system. Where/When should it exist? Can we factor that logic out to be more semantic instead of doing brittle bash if/then/else checks?

Well, NixOS isn't a distinct platform from Linux in Nixpkgs, right? There's the additional problem that on macOS, either can appear. With a plain Nix install on macOS, we'll have the profile.d/nix.sh script, but if one is using nix-darwin, they'll also have a module system like on NixOS, and we should prefer its config. If on that platform we always read the nix.sh file, things controlled in setEnvironment (like the environment variables relating to whether and where to find the Nix daemon) will be ignored.

The idea of this PR is to pull a small part of the NixOS Fish initialization process, namely the part that makes Nix-installed binaries usable by Fish config snippets in ~/.config/fish/conf.d and $__fish_sysconfdir/conf.d, out into Nixpkgs so that it will be usable outside of NixOS. The other bit, discussed in the thread above, is in part just a consequence of moving that code into Nixpkgs and in part an effort to make sure that with these changes Fish does not become less functional/compatible on NixOS OOTB than it is on non-NixOS.

@Profpatsch I was just looking at the Nix package in Nixpkgs and it seems like maybe we could add stateDir to nix.passthru and then use that in the Fish package. Does that make sense? Alternatively, could we maybe expose it in the stdenv in its own right along side $NIX_STORE as something like $NIX_STATE?

maybe we could add stateDir to nix.passthru

I’m not sure we even need to find the state dir. Can you point me to documentation by what these shell files are generated on each system?
It feels to me like those are (undocumented) nix interna that shouldn’t be depended upon. So before we use them, the interface should be documented and standardized.

I’m not sure we even need to find the state dir. Can you point me to documentation by what these shell files are generated on each system?

The reason we need to find the state directory is because we need to find a Nix profile (the default profile, which gets the nix.sh and nix-daemon.sh files) before NIX_PROFILES is set. The state directory we only really need to find that default profile (instead of assuming it lives under /nix/var/nix/..., as that can change at compile time.

I don't think there's any documentation about it, but the files get put in the appropriate directories here and the templates for them are here (for no Nix daemon) and here (to a Nix daemon).
All I really need is a reliable place in which to find these shell scripts that Nix uses to set up the environment, both for NixOS and non-NixOS. I'm not invested in how it's exposed-- what I did here was find something that works for a typical Nix installation (i.e., any Nix which hasn't been compiled to use a non-default state directory).

It feels to me like those are (undocumented) nix interna that shouldn’t be depended upon. So before we use them, the interface should be documented and standardized.

This is a fair point, and I should have followed through with it when I first read it. Who should I contact about this and how?

Would rename to nix/support/fish-set-environment.sh.

I have this set in this location because it's identical to the usual setEnvironment script and exposing it this way makes it usable by Nix packages which may not know whether or what module system they have. I'd like for it to potentially be usable by other non-POSIX shells which may have to resort to similar tricks if we're not to maintain several initialization scripts for Nix. (Elvish is the shell I have in mind.)

Maybe I should say I'm not gonna need it, call it fish-set-environment.sh and rename it only when it is actually used by another shell. What do you think?

I’m not quite sure I understand the reason for exposing this file in the first place. Since it’s exposed via the module system, you have to use NixOS anyway to use it, so why not add it to fish and other shells directly when building their config?

Well, set-environment is roughly the equivalent of the profile.d/nix.sh script on NixOS and in nix-darwin. The idea is that Fish installed via Nix should at a minimum ‘just work’ with the very basics of Nix (setting up the NIX_… environment variables and adding the Nix profile directories to the PATH.

This PR adds functionality that makes Fish-from-Nixpkgs usable as a login shell OOTB on non-NixOS. Exposing the setEnvironment file allows NixOS to have the same level of functionality prior to enabling the NixOS module. But the NixOS module still adds properly NixOS-specific functionality, like reading all the global shell configurations.

For the feature to work the same way across NixOS and non-NixOS, something equivalent to the profile.d/nix.sh file for NixOS has to be exposed prior to user configuration, and as far as I can tell setEnvironment is it.

Looks like this went in directly under /etc here

If pushing for documentation/standardization is still warranted (it probably is) that's now the thing to document

nit: why here (between system.build.setEnvironment and system.activationScripts.binsh), not in the environment. section above?

No good reason. I'll go ahead and move it.

That’s brittle. Why not writeText and source?

That’s brittle. Why not writeText and source?

You mean specifically the indentation hack? Because it works, the stakes are low (the whitespace here won't break anything), and it seems good to avoid sourcing additional files during shell startup if possible. It's also more readable.

I can let that go, though.

If you want to avoid opening files, I’d hate to tell you how many unsuccessful stats most of the software we use do, searching for files in locations that are just crazy by nix standards …

maybe we could add stateDir to nix.passthru

I’m not sure we even need to find the state dir. Can you point me to documentation by what these shell files are generated on each system?
It feels to me like those are (undocumented) nix interna that shouldn’t be depended upon. So before we use them, the interface should be documented and standardized.