use writeShellApplication for probe's exec.command

[adrian-gierakowski]

It's confusing since code in probes exec.command behaves differently than in process command, since $variable needs to be escaped ($$) in order to be resolved at runtime, instead of at config parsing time

for example, the following in probe's exec.command

a=something
echo "a: $a"

would print a: unless env var a was set when PC was started

in order for it to behave like in process command, it would need to be:

a=something
echo "a: $$a"

see:
F1bonacc1/process-compose#63
F1bonacc1/process-compose#63 (comment)

[srid]

We used to use writeShellApplication until 47afdda

See #22 (cc @belevy).

---

Regarding this:

a=something
echo "a: $a"

(Presuming you assigned this whole string to exec.command)

Wouldn't you want to use settings.environment.a = ... instead?

process-compose-flake/example/flake.nix

Lines 33 to 36 in 1012530

	settings = {
	environment = {
	SQLITE_WEB_PASSWORD = "demo";
	};

[srid]

See also 2nd point in https://community.flake.parts/process-compose-flake#module-api

[adrian-gierakowski]

hah, just realised that process.command doesn't actually use writeShellApplication, however it does do this:

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

Lines 6 to 10 in 1012530

	apply = pkg:
	if builtins.isString pkg
	then pkg
	else lib.getExe pkg;
	})

which makes it easier to use with writeShellApplication

so I guess I'd like to change this issues, to use the same trick for exec.command

[srid]

Yup, we tend to use writeShellApplication for anything that's not a single command invocation, examples:

https://github.com/search?q=repo%3Anammayatri%2Fnammayatri%20command%20writeShellApplication&type=code

[adrian-gierakowski]

Wouldn't you want to use settings.environment.a = ... instead?

No, I'd like to be able to write in-line shell scripts which don't behave as expected.

[adrian-gierakowski]

would it be possible to add a global config which would cause all commands to be automatically wrapped with writeShellApplication?

IMHO it's a saner default in the light of PC's intuitive env substitution behaviour, but I get that some people might want to avoid the extra indirection, so having it configurable would be nice

[adrian-gierakowski]

btw. why use apply = pkg: instead of lib.types.coercedTo ?

[adrian-gierakowski]

would it be possible to add a global config which would cause all commands to be automatically wrapped with writeShellApplication?

happy to submit a PR

[srid]

PC's intuitive env substitution behaviour

Could you link to PC's official documentation on this?

[srid]

Looks like, it is this: https://f1bonacc1.github.io/process-compose/configuration/?h=%24%24#disable-automatic-expansion

[srid]

That link only talks about disabling environment expansion. I still don't understand just what exactly it expands to.

Using this example from the docs,

processes:
 foo:
     command: echo I am $ENV_TEST
    environment:
     - 'ENV_TEST=ready'

Where does PC lookup to expand the ENV_TEST (if not the environment specified there)?

[adrian-gierakowski]

ah, forgot that disable_env_expansion: true has been added!

without disable_env_expansion: true any occurrence of $something anywhere in the yaml config get expanded based on env at the time PC is executed and the config is first parsed

environment affects then env of process at runtime, but by then $ENV_TEST would have been replaced with empty string by the parse time expansion

some related issues:
F1bonacc1/process-compose#120
F1bonacc1/process-compose#179

[adrian-gierakowski]

before 1.6.1 there was no way to escape\disable this behaviour

anyway, making exec.command behave the same as process command in this project would be nice

same for auto-wrapping with writeShellApplication as it adds extra safety with built time check

[adrian-gierakowski]

try:

processes:
  foo:
    command: echo I am $$ENV_TEST
    environment:
     - 'ENV_TEST=ready'

which should print I am ready

or:

processes:
  foo:
    command: echo I am $ENV_TEST

and then

ENV_TEST=ready process-compose

[srid]

Yup, I understand it now. PC expands with the environment it itself inherits (like $USER), as distinct from what's in the config file. Thanks.

anyway, making exec.command behave the same as process command in this project would be nice

Hmm, could you clarify? What is "process command" (that exec.command is not the same of)?

would it be possible to add a global config which would cause all commands to be automatically wrapped with writeShellApplication?

same for auto-wrapping with writeShellApplication as it adds extra safety with built time check

I'm still thinking about this. In general, less magic -- i.e., being more straightforward -- is preferred.

I don't see the point of this env expansion behaviour, to be frank. Doesn't that introduce ... an element of impurity? What if we set disable_env_expansion to true by default? Or am I missing something?