I have envfs and nix-ld enabled on my machines.
Specifically for development, it makes it easier to jump into new projects without going trough this whole “purification” phase. Please don’t take it too literally, but here is a carricature of the “pure” path, vs the green envfs + nix-ld one:
For projects I run, I still go trough the trouble of the black path, because it’s getting repaid over time. But I find it’s not worth it when all you want to do is fix upstream and send a PR.
Can I use your photo 
I mostly fall back to distrobox if I want to try something (like a pip install) without having to fiddle with nix. A similar approach could be used with nix, I think steam-run is kind of like that. E.g. having pip-run-with-manylinux-fhs which would set up the manylinux FHS in a mount namespace so you can just use pip normally would be nice. That would preserve the “temporary” nature of nix-shell.
I think programs.nix-ld.enable is enabled in the default generated installer config?? I may be mistaken, it might be stub-ld instead…
since envfs is $PATH based and dynamic it’s effectively “temporary” to the nature of a nix-shell as well!
nix-ld is definitely not enabled by default. n-g-c also doesn’t touch stub-ld either, the default value on NixOS is just to enable it:
Ah ok, nice, I misunderstood how it works then, I’ll need to give it a proper try!
There are corner cases where environment variables changes are not visible to the approach that envfs is using it via FUSE, so I prefer the simpler glibc wrapper that is more robust and doesn’t require any external process to run.
FUSE doesn’t not require user namespaces. Not sure if mount.fuse uses usernamespaces for unprivileged mounts in some cases, but for envfs we are mounting the filesystems as root.
Understood for root, point taken
