TLATER, @NobbZ, thank you for your comments!
Re nix-shell vs nix: I vaguely remember something along the lines of nix-shell being a utility specific to the “proper” installation of Nix, and nix being a new-generation utility, for which static builds are available. Maybe this is no longer the case, or maybe I just had the wrong idea about this from the very beginning, thank you for correcting me!
I have tried adding openssh into the flake that I have been using, and the result is somewhat unexpected: even though from within the Nix shell ssh now corresponds to the OpenSSH binary inside the Nix store, this binary still looks up the system-wide configs, for which the ownership is messed up by the sandbox/namespace mechanisms. By the way, the system-wide configs are used even if I revert all my attempts to disable the Nix sandbox. I can tell this binary to actually use configs inside the Nix store with ssh -F /nix/store/law40w42z5j8abrlz9xwir82aaf36iqb-project/etc/ssh/ssh_config, and then it works as expected. I wonder if you think this is a bug with the Nix build of openssh? I believe it should not, unless explicitly instructed, try to access system-wide configs. I can report a bug if you think this is worthy of attention.
So all these experiments lead me to believe that I should indeed abandon the approach I have been taking so far, because it is messy and, apparently, doesn’t follow the best practices.
I wonder what you would suggest me to do? The ultimate goal is that my unprivileged user is able to install the binaries that are missing system-wide (or are outdated system-wide), their versions can be locked down and easily reproduced elsewhere (100% binary reproducibility is not required), and they can be updated on-demand. All this should ideally come with minimal disruptions to the functioning of the software installed system-wide.
So far I have been using Miniforge to achieve this, and I was mostly happy with the solution. My attempts to move to Nix are mostly due to my idea that Nix has more (and more up-to-date) software and would therefore be a better choice in general, but it’s not like I lacked something when I used Miniforge. I can go back to this solution if Nix doesn’t end up working for my use-case.
Another option I see is that I continue using a Nix flake, but rather than dropping to the Nix shell on login, I create wrappers for every binary that I want to use from this flake, and put them under ~/.local/bin such that, for example, ~/.local/bin/yazi is a wrapper for nix shell ~/flake -c yazi, and so on for every binary. That way I get version lockdown and reproducibility through flake.lock, and can update all the software by removing the lock file. The downside is that I should be mindful of the sandbox, and avoid doing something like “run a file manager from the flake, drop into a shell from this file manager and then attempt to use SSH”.
I would greatly appreciate any comments about these and other possible approaches!
I would also like to politely request @twhitehead’s comments if possible. You were very helpful in the previous thread of mine, here. I wonder if you can suggest something here…?
Thank you so much!