Commands shouldn't be automatically wrapped in a shell application

[belevy]

writeShellApplication does a lot and it seems strange to wrap a single line command in its own bash script.

Further it is not intuitive that my command is going to be wrapped in a shell script where the rest of the options in the config are treated as directly being added to the process compose config file this one attribute is being treated specially.

[srid]

process-compose-flake/nix/process-compose/settings/command.nix

Lines 7 to 11 in dd1dff0

	if builtins.isString pkg
	# process-compose is unreliable in handling environment variable, so let's
	# wrap it in a bash script.
	then lib.getExe (pkgs.writeShellApplication { inherit name; text = pkg; })
	else lib.getExe pkg;

Without this, the example will not even run (the environment variables are unset for some reason). Try:

diff --git a/nix/process-compose/settings/command.nix b/nix/process-compose/settings/command.nix
index 05a58e3..f090146 100644
--- a/nix/process-compose/settings/command.nix
+++ b/nix/process-compose/settings/command.nix
@@ -7,6 +7,7 @@ lib.mkOption (args // {
     if builtins.isString pkg
     # process-compose is unreliable in handling environment variable, so let's
     # wrap it in a bash script.
-    then lib.getExe (pkgs.writeShellApplication { inherit name; text = pkg; })
+    # then lib.getExe (pkgs.writeShellApplication { inherit name; text = pkg; })
+    then pkg
     else lib.getExe pkg;
 })

followed by:

cd ./example
nix run --override-input  process-compose-flake .. .

[srid]

The main problem here is the user surprise (when their env var is unset). If there is an alternative solution, let me know. For now, I've documented the expectations in the README: 28bb6fc

[srid]

Okay, I've talked to Ben, and I'm convinced that we should not wrap command in a shell script. The README should recommend people to use writeShellApplication if their command becomes more script-like (using env vars and such).