Additionally, it eliminates the concern of influencing builds in nixpkgs if people have /bin/bash on their system. As long as you build with --pure, the environment variable is unset and any scripts depending on the absolute location of /bin/bash will fail.
A very reasonable and workable solution, IMO.
2 Likes
I noticed among the config options the existence of https://nixos.org/manual/nixos/stable/options#opt-services.hadoop.yarn.nodemanager.addBinBash – it looks like that requires installing Hadoop, but the implementation is quite simple so now I’m using systemd.tmpfiles.rules to create a /bin/bash symlink. Seems to work so far (admittedly I haven’t say rebooted yet).
(I don’t really understand the reproducibility issues – there’s tons of ways for configuration.nix to change how a system behaves, right? Is an option to install a /bin/bash symlink really uniquely bad?)
1 Like
For somebody who wants a more standard experience, I recommend to install these two things on your system:
- GitHub - Mic92/envfs: Fuse filesystem that returns symlinks to executables based on the PATH of the requesting process.
- GitHub - Mic92/nix-ld: Run unpatched dynamic binaries on NixOS
This removes a big chunk of the issues you get when running arbitrary scripts and binaries that come from the Internet.
12 Likes
I previously added a handful of symlinks in /bin and /usr/bin with sudo ln -s /run/current-system/sw/bin/.... (not sure why you would need a NixOS option to do this).
But am now a happy user of envfs. It’s a much neater solution. Dare I suggest that it be enabled in the nixos-generate-config template?
For me, the problem is often scripts with /usr/bin/python. I try to push changes upstream but this isn’t always easy or fun.
3 Likes
Search threads for shebang issues. Envfs was the saviour for me. Tbh its little things as this literally deters new users away.
3 Likes
Yes, Envfs is great! Do make it easier to people coming here for a solution, here is the full answer:
2024 I think the way to go is:
# configuration.nix
services.envfs.enable = true;
Fuse filesystem that returns symlinks to executables based on the PATH of the requesting process. This is useful to execute shebangs on NixOS that assume hard coded locations in locations like /bin or /usr/bin etc.
If you also think so, please help to upvoid this or accept as a solution
3 Likes
Nix is a tool to ensure correct deployments, and NixOS is supposed to be the distro that is correctly-deployed. So, I think envfs and nix-ld fundamentally subvert the entire point of NixOS, and ideally would not get recommended ever. We already have enough headaches with things like the graphics driver impurities.
From a packaging perspective, fixing this should be the responsibility of patchShebangs, autoPatchelfHook, etc in fixupPhases.
8 Likes
This has been discussed a few times already, but part of nix-ld’s advantage is to allow you to use your system when there is no quick way to package a program or when quickly prototyping/testing. Being elegant is nice, useful is better. For instance just try to develop with npm or java that love to import pre-packed binaries… I was mad before nix-ld came to the rescue.
3 Likes
This has nothing to do with “elegance”, if nix wasn’t useful then we wouldn’t use it. The entire point is solving DLL hell, these hacks only bring us back to that hell.
Not everyone finds nix useful, and that’s fine, but if you use nix and complain that nix is doing its one job as designed then I find that obviously misguided and would suggest the user use a different distro. It’s like complaining that Arch isn’t stable, it’s not meant to be, and there are other better distros for that need.
EDIT: I would also question what brought the user to NixOS and if we are producing some misleading marketing.
10 Likes
In fairness, nix-ld does help solve problems that are otherwise impossible - or nearly so - to fix, e.g. running VMs/debugging with android atudio, since it insists on downloading its own binaries at runtime to do so, and patching those manually is unreasonably much work at best.
While I agree that they’re best avoided, we live in a world that isn’t NixOS-oriented; sometimes this means that we need to incur some impurity for compatibility.
nix-ld actually does all this in a rather inoffensive way, too, as it remains a no-op until you set the NIX_LD variable. What we really should be doing is making sure people know that setting that variable globally is a bad idea; I really wish that wasn’t the default setting of the option.
I’m less of a fan of envfs, patching shebangs isn’t hard manually, and it’s much less common for third party binaries to hardcode /bin/bash (let alone other binaries). Though when they do you have no other options besides an fhsenv, which isn’t always possible (see android studio), so again sometimes it’s a necessary evil.
Now you can say “just use Arch/Gentoo/Debian/Fedora/Silverblue” then, but I rather like declarative config, so Imma keep using NixOS and hack around the limitations of android studio the few times I need to instead.
4 Likes
Last time I used it, it was wrapped in an FHSEnv for this reason and that’s precisely the case we have those for.
3 Likes
Fair, maybe it needs some work then, it definitely did not play ball with flutter a month or two ago.