The use of wrapper scripts to set or change environment variables before running the real executable has become very widespread in nixpkgs. While they are important for making programs run out-of-the-box, wrappers have some general problems. Some of these could be fixed but some are perhaps unfixable. I'm writing this to generate some discussion to see if we could solve some of these issues or come up with an alternative solution.

1. Environment variables are propagated to child processes. I believe this is the most problematic thing. The intent of the wrapper is to make the wrapped program run correctly, and the fact that child processes see the adjustment is unintended leakage of information/configuration. Any child process started by the wrapped program that also needs environment changes will generally have its own wrapper. This leakage could cause another application to run incorrectly or differently than if it was started "cleanly".

2. Wrappers which add to list-type variables (typically colon-separated) will add the value unconditionally without checking if it is already in the list.

To observe (1) and (2) in action, open Konsole and run echo "$XDG_DATA_DIRS". Then type konsole in the same terminal and run the echo in the new terminal. You will see that the variable contains two entries for <konsole-store-path>/share. You can keep repeating this to get XDG_DATA_DIRS that grows without bounds.

3. Wrappers obscure the process name. Just look at a process list and find many .something-wrapped processes.

4. People forget to make wrappers and/or don't know which variables need to be set. For example, probably most GTK apps need to have GDK_PIXBUF_MODULE_FILE set to point to some file in the librsvg package. It is far from obvious to a random person packaging an app that this is necessary (see gdk-pixbuf: Use a different GDK_PIXBUF_MODULE_FILE environment variable on 32-bit and 64-bit systems. #60254 and Use a NixOS module for generating the gdk-pixbuf loaders cache. #42562).

5. Wrappers break software that opens the executable and expects it to be an ELF binary. I have encountered this with Wine but I have not yet filed an issue (it results in very suble but widespread breakage). But this is uncommon.