"A big implication of the way that Nix/NixOS stores packages is that there is no /bin, /sbin, /lib, /usr, and so on. Instead all packages are kept in /nix/store. (The only exception is a symlink /bin/sh to Bash in the Nix store.) Not using ‘global’ directories such as /bin is what allows multiple versions of a package to coexist. Nix does have a /etc to keep system-wide configuration files, but most files in that directory are symlinks to generated files in /nix/store."
Ok, if env is supplied then scripts can at least use it to locate Python, etc. which makes a lot of sense. The text made it sound like these directories did not exist at all.
If you as a user wish to have a normal-ish Unix commandline experience, you "install" into your personal nix profile various nix packages. I put "install" in quotes because there are two steps:
1) Adding the package to the nix store, /nix/store/checksum-coreutils-version
2) Linking this into your nix profile: ~/.nix-profile/bin/ls will be a symlink to /nix/...coreutils.../bin/ls
Your PATH is then ~/.nix-profile/bin.
Now if you're packaging a shell script, and it calls coreutils and rsync, then inside the build scripts for that package, you might do something like this to wrap the script with the required PATH:
That way, the script will still work even if the user running it does not have coreutils or rsync in PATH. If will also work if the user does have rsync-1.0, but the script requires rsync-2.0, because the custom PATH being used by the script includes the required rsync.
In this situation, both coreutils and rsync would be present in /nix/store, even if no user has linked them into their profile.
