Hey Marius,
> If you are on Guix System and find that you need /usr/bin/env, you are > already a "power user": you are venturing outside of what is provided by > Guix alone. I don’t follow this argument. Using a custom script with a /usr/bin/env shebang is pretty common. You don’t need to be a power user for that, and certainly not a *Guix* power user. On the other hand I’d like to point out that pretty much all defaults we provide in system services can be overridden — and that’s where it helps being an advanced user. This is true for things like the desktop services (which aim to make setting up a generic desktop system easy and non-surprising), but also for every other service. Personally, I think it’s a good idea to default to having /usr/bin/env shebangs just work on Guix Systems. The argument that /usr/bin/env could make software work by accident when testing on a Guix System is not very convincing to me. We don’t have /bin/sh or /usr/bin/env in the build environment. Software behaviour is also affected by the presence of /usr, /lib, /bin, etc, and these can all exist at runtime. We assume that building in an isolated environment is usually sufficient; and yet we sometimes find that applications behave differently when run inside of containers (e.g. applications that call out to coreutils that are usually available in a normal system). With the same reasoning we could argue against having coreutils on PATH. This is not an exaggeration: R depended on coreutils to be on PATH at runtime and we only found out when we ran it in a container without coreutils. Am I missing something? -- Ricardo
