Open tfh-cri opened 7 months ago
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?
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.
I'm trying to use a task along the lines of:
but on invocation the
ENV_PROJECT
value isn't interpolated as I'd ( perhaps naively) expect: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?