Remix.run Logo
nh2 4 hours ago

Worth pointing out that with Nix/NixOS this problem doesn't exist.

The problem in other distros is that if you prefix PATH so that it contains your executable "foo", and then run a program that invokes "foo" from PATH and expects it to do something else, the program breaks.

With Nix, this problem does not exist because all installed programs invoke all other programs not via PATH but via full absolute paths starting with /nix/store/HASH...

ahepp 2 hours ago | parent | next [-]

The "solution" of only ever using full absolute paths works on any unix system, doesn't it?

aidenn0 an hour ago | parent [-]

Yes with a but:

NixOS simultaneously smooths the path to using absolute paths while putting some (admittedly minor) speed-bumps in the way when avoiding them. If you package something up that uses relative paths it will probably break for someone else relatively quickly.

What that means is that you end up with a system in which absolute paths are used almost everywhere.

This is why the killer feature of NixOS isn't that you can configure things from a central place; RedHat had a tool to do that at least 25 years ago; it's that since most of /etc/ is read-only, you must configure everything from a central place, which has two important effects:

1. The tool for configuring things in a central place can be much simplified since it doesn't have to worry about people changing things out from under it

2. Any time someone runs into something that is painful with the tool for configuring things in a central place, they have to improve the tool (or abandon NixOS).

ablob 3 hours ago | parent | prev [-]

So if I want to use grep in a small script, do I have to write:

/nix/store/grep-hash -flags files | /nix/store/head-hash

instead of: "grep -flags files | head"?

aidenn0 35 minutes ago | parent | next [-]

If it's a one off, you just use something like "nix shell" to add it to your path for running the script.

For non one-off sorts of things, you would substitute in the nix expression "${gnugrep}/bin/grep" the "${gnugrep}" will expand to "/nix/store/grep-hash" and also make a dependency on the gnugrep package, so that the grep install won't get garbage-collected as long as your package is still around.

Here's an example[1] from a package expression for e-mail client I use, which will shell out to base64 and file. Upstream relies on these two programs being in $PATH, but this replaces the string used for shelling out with the absolute path in the nix store.

For shell scripts, I'll just do something like this near the top:

   GREP="${GNU_GREP:-$(command -v grep)}"
Then I use "$GREP" in the script itself, and develop with grep in my path, but it's trivial to prepend all of my dependencies when I bundle it up for nix.

1: https://github.com/NixOS/nixpkgs/blob/master/pkgs/by-name/no...

xaduha 3 hours ago | parent | prev [-]

    [user@nixos:~]$ which grep
    /run/current-system/sw/bin/grep

    [user@nixos:~]$ ls -l /run/current-system/sw/bin/grep
    lrwxrwxrwx 1 root root 65 Jan  1  1970 /run/current-system/sw/bin/grep -> /nix/store/737jwbhw8ji13x9s88z3wpp8pxaqla92-gnugrep-3.12/bin/grep
Basically, it is still in your environment, so I don't see how he can claim that this problem doesn't exist in Nix, unless you use flakes like a proper Nix afficionado.