Using argument values to interpolate into task env values in cmd/shell tasks?

[tfh-cri]

I'm trying to use a task along the lines of:

[tool.poe.tasks.env-from-arg]
args = [
  { name = 'project', type='string', options=['--project'], default="staging" }
]
env = { ENV_PROJECT = "--someflags=${project}-suffix" }
cmd = "echo raw arg is ${project} and value from env is $ENV_PROJECT"

but on invocation the ENV_PROJECT value isn't interpolated as I'd ( perhaps naively) expect:

-> % poe -vv env-from-arg
Poe => echo raw arg is staging and value from env is --someflags=-suffix
raw arg is staging and value from env is --someflags=-suffix

-> % poe -vv env-from-arg --project somevalue
Poe => echo raw arg is somevalue and value from env is --someflags=-suffix
raw arg is somevalue and value from env is --someflags=-suffix

I suspect this might be a result of the order of operations/expansions of the task settings - because the args are passed into envvars themselves, and because they override the task.env settings and other inherited stuff, they're not actually available to support this sort of usage?

Is this intended behaviour, or could it potentially update task.env to set the arg values prior to expanding the task definitions, then a second time after to ensure overrides behave as expected?

[tfh-cri]

As a workaround, its easy enough to do something like:

[tool.poe.tasks.env-from-arg]
args = [
  { name = 'project', type='string', options=['--project'], default="staging" }
]
shell = """export ENV_PROJECT="--someflags=${project}-suffix"; echo raw arg is ${project} and value from env is $ENV_PROJECT"""

but maybe a note in the docs might be useful to stop others tripping up the same way?

[nat-n]

Hi @tfh-cri,

Yes, your hunch is correct about the cause. Being able to make an argument take a default value from the environment (which I find quite useful), implies that the env is resolved before args are evaluated, and so can't depend on passed args. Maybe there's a way to have it both ways, which would be nice, but I fear it would add much complexity to the implementation by requiring multiple passes to resolve env vars.

I agree that this is probably worth clarifying in the docs, I'll leave this issue open for now as a reminder for me to improve the docs.