`nixsa` can't be launched from `nixsa`

[alurm]

I'm not sure how much of an issue this is in practice, but maybe this issue helps somebody.

Minimal example

$ nixsa nixsa
Error: Couldn't find a directory containing /proc/self/exe which contains a `nixsa.toml` file.

The error is a bit confusing.

Why this happens

1. nixsa/nixsa-bin/src/main.rs

   Line 204 in ef616c6

   let nix_sh = basepath.join("state/profile/etc/profile.d/nix.sh");

2. Nixsa is installed into the nix profile.
3. At the end of nix.sh, we have export PATH="$NIX_LINK/bin:$PATH"

So a nixsa from /nix/store gets launched, which only has bin/nixsa and no nixsa.toml.

Workarounds

Don't launch nixsa from nixsa.

Potential solutions

I don't know. Maybe nixsa can be prepended to path after nix.sh is sourced? But maybe this introduces different issues.

Maybe the issue can be made less confusing by providing an error message that is easier to understand. It took me a while to figure out why you can't launch nixsa from nixsa (I couldn't get it why it can't find nixsa.toml).

Not installing nixsa to the default profile also seems wrong.

---

How I encountered this

I encountered this because I used exec nixsa fish in my ~/.config/fish/config.fish to use a fish more recent than my system's. (To be fair, maybe this isn't the best solution to my problem.)

Then, nixsa can't be used from fish. Also, tmux and other programs which launch a login shell in their default configuration can't be used.

[noamraph]

Thanks @alurm for this great bug report!

I want to share some thoughts. I'm not sure what is the ideal solution, but I'm sure something can be done to improve the nixsa-in-nixsa experience.

First thought: the reason nixsa is a part of the profile is to allow updating to a different version of nixsa. It's not really useful to have nixsa installed to the PATH of the nixsa environment. Perhaps just moving the nixsa static executable to a different place inside the nixsa-bin-static package would do the trick - say, libexec instead of bin. This may simply fix this issue.

Second thought: currently, you can actually run nixsa inside nixsa, if you run if from where you really installed nixsa, not from /nix/store. However, it creates another bwrap sandbox, which works, but seems wasteful. Here's an idea, let me know what you think. When Nixsa runs, it will look at the environment variables which are set by nixsa (NIX_USER_CONF_FILES, NIX_CACHE_HOME, etc). If all of them match being set by Nixsa, meaning they all are the Nixsa base dir plus some suffix, stat /nix/store and see if it is the same inode as NIXSA/nix/store (where NIXSA is the common prefix). If so, Nixsa would just run the executable without any bwrap invocation.

What do you think?

Thanks again!

[alurm]

Sorry for the long reply. I fixed my issue by launching into Fish directly.

I like the second approach. But, unless I'm mistaken, it seems to me that you would need to the location of nixsa.toml (or the directory where it resides) with that approach, too.

I can think of two ways to do this. (1) As you suggested, move nixsa out of bin (e.g. to libexec) and make a helper that would provide the location of nixsa.toml to the main binary. (2) Set the location of nixsa.toml in an environment variable if it's not set.

But, it seems to beg the question: wouldn't setting a marker variable be enough to indicate that we're in nixsa? That seems simple. It would still be possible (but not convenient) to recursively launch nixsa in nixsa by unsetting the variable, I believe (not sure where it would be useful).