Unexpected behavior when using arguments with sequence and switch tasks

[starhel]

Using task arguments together with a sequence task that contains a switch block behaves unpredictably. The variable resolution inside control.expr appears inconsistent depending on argument type and syntax, even though the same patterns work correctly when switch is used outside of a sequence.

Example 1 — String argument fails unless wrapped in ${...}

[tool.poe.tasks.reproduction]
args = [
    { name = "BUILD_TYPE", options = ["--build-type"], default = "release" }
]

[[tool.poe.tasks.reproduction.sequence]]
control.expr = "BUILD_TYPE"
switch = [
    { case = "release", cmd = "echo build release"},
    { case = "debug", cmd = "echo build debug" }
]

In this case, Poe throws: Error: Invalid variable reference in expr: BUILD_TYPE. According to the documentation, using the bare argument name should work with switch tasks, and indeed it does work correctly when switch is not nested inside a sequence.
Using control.expr = "${BUILD_TYPE}" works as expected - until the argument type changes to boolean.

Example 2 — Boolean argument breaks when using ${...} syntax

[tool.poe.tasks.reproduction]
args = [
    { name = "RELEASE", options = ["--release"], type = "boolean" }
]

[[tool.poe.tasks.reproduction.sequence]]
control.expr = "${RELEASE}"
switch = [
    { case = true, cmd = "echo build release"},
    { cmd = "echo build debug" }
]

This configuration results in: Error: Expected a single python expression, instead got:. I can define default = false, but then the argument is always set, which prevents using an alternate-value operator to detect whether the flag was provided or omitted.

control.expr inside sequence does not resolve arguments the same way as a top-level switch task, rejecting bare variable references like BUILD_TYPE. From my point of view, argument values should be accessible inside control.expr consistently across task types. Using sequence and switch tasks together is extremely convenient in build pipelines, where certain steps need to run before or after the actual build process.

[nat-n]

Hi @starhel, thanks for the feedback! This is an interesting use case (and edge-case) that I hadn't thought about.

I see how this is surprising. The issue is that the task composition mechanism is actually quite naive, the switch task inherits the sequence task's environment variables but doesn't know which ones are arguments. I'm marking this issue as an enhancement to track that this could be improved.

In the mean time, I can suggest some workarounds:

1. As I guess you saw, referencing the arg from the sequence task in your first example as control.expr = "${BUILD_TYPE}" should work as expected.
2. What might be less obvious in the second example is that since expr tasks are python expressions you can get what you want with control.expr = "bool(${RELEASE})"

TODO

• explore how to make inline tasks aware of parent task args

[starhel]

A very nice workaround using the bool function, thanks!