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: https://github.com/F1bonacc1/process-compose/issues/63 https://github.com/F1bonacc1/process-compose/issues/63#issuecomment-1615161806

[srid]

We used to use writeShellApplication until 47afddae52faffb70621db9d4123684474c6ddfe

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?

https://github.com/Platonic-Systems/process-compose-flake/blob/1012530b582f1bd3b102295c799358d95abf42d7/example/flake.nix#L33-L36

[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:

https://github.com/Platonic-Systems/process-compose-flake/blob/1012530b582f1bd3b102295c799358d95abf42d7/nix/process-compose/settings/command.nix#L6-L10

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: https://github.com/F1bonacc1/process-compose/issues/120 https://github.com/F1bonacc1/process-compose/issues/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?

[adrian-gierakowski]

btw. parse time expansion can be used to set any part of the config

shell:
  shell_command: $SHELL_COMMAND

and then:

SHELL_COMMAND=python process-compose

[adrian-gierakowski]

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)?

process command coerces package to string with lib.getExe: https://github.com/Platonic-Systems/process-compose-flake/blob/1012530b582f1bd3b102295c799358d95abf42d7/nix/process-compose/settings/command.nix#L6-L10

exec.command is just a string

https://github.com/Platonic-Systems/process-compose-flake/blob/1012530b582f1bd3b102295c799358d95abf42d7/nix/process-compose/settings/probe.nix#L58-L59

[srid]

Oh yea, we should do that. See https://github.com/Platonic-Systems/process-compose-flake/issues/32#issuecomment-1636875136

[adrian-gierakowski]

I don't see the point of this env expansion behaviour, to be frank. Doesn't that introduce ... an element of impurity?

yeah, it's a footgun IMHO, but might be useful for people who don't use nix/process-compose-flake

What if we set disable_env_expansion to true by default? Or am I missing something?

💯 (just warn the users in the docs)

[srid]

just warn the users in the docs

Yea, I'd a welcome a PR on that too :-)