Pass arguments to ref tasks

[guillaume-alliander]

Starting to use poe, which is way nicer than my homebrew scripts, thanks for that!

One thing I am trying to do is to pass parameters (not the value!) in a sequence

[tool.poe.tasks.all]
sequence = ["format ${check}", "something_without_args"]
args = [{name = "check", type="boolean"}]

[tool.poe.tasks.format]
cmd = 'ruff format ${check:+ --diff}'
args=[{name = "check", type="boolean", help= "Does not correct files, only warns"}]

[tool.poe.tasks.something_without_args]
expr = "not relevant"

Now:

• poe format => formats file
• poe format --check => warns is the file is not formatted
• poe all => should format and run the other not relevant task
• poe all --check => should warn about formatting and run the other not relevant task

The thing is that format requires the string --check, not the value (True). Currently I get (expectedly) poe format: error: unrecognized arguments: True.

Is there a way to pass arguments as-is, not there value? i have seen that it is possible to pass values as environment variables, but that is not the behaviour I am looking for,

[nat-n]

Hi @guillaume-alliander, Good question!

Sadly I'm not sure there's a nice way to do exactly what you're asking for.

I guess one nice solution would be if ref tasks also accepted the advanced syntax for parameter expansion ${check:+ --diff}. I've been planning to make this syntax acceptable in more places so I'll add this to my list.

Another approach would be to implement another missing feature I've been considering for a while (but I'm not yet convinced about a design) which is to allow all unparsed arguments to be accessed via a single variable like "format ${ALL_ARGS_GO_HERE}".

Fantasies aside, a not very satisfying workaround could be to use an switch task like the following example which executes a different sequence depending on whether the --check option is provided (untested):

[tool.poe.tasks.all]
control.expr = "check"
args         = [{name = "check", type="boolean"}]
  [[tool.poe.tasks.all.switch]]
  case     = "True"
  sequence = ["format --diff", "something_without_args"]
  [[tool.poe.tasks.all.switch]]
  sequence = ["format", "something_without_args"]

[tool.poe.tasks.format]
cmd = 'ruff format ${check:+ --diff}'
args=[{name = "check", type="boolean", help= "Does not correct files, only warns"}]

[tool.poe.tasks.something_without_args]
expr = "not relevant"

[guillaume-alliander]

Thanks for the workaround! it will indeed work.

Thinking further, I think I would love a passthrough option. Otherwise tasks would need to know how to handle different types of arguments, or ref would need to manipulate arguments to simulate a direct call, and that feels a bit clunky.

Ideally, from a user perspective, I would see something like this design wise:

[tool.poe.tasks.all]
sequence = [
  { ref = "format", passthrough=["arg1"] },
  { ref = "something_else", passthrough=["arg2"] },
  { ref = "yet_another" },
]
args = [
  {name = "arg1", type="boolean"},
  {name = "arg2", type="string", positional=True},
]

[tool.poe.tasks.format]
cmd = 'blah <normal usage of arg1>'
args = [
  {name = "arg1", type="boolean"},
]

[tool.poe.tasks.something_else]
cmd = 'blah <normal usage of arg2>'
args = [
  {name = "arg2", type="string", positional=True},
]

[tool.poe.tasks.yet_another]
cmd = 'blah'

To be even less verbose:

[tool.poe.tasks.all]
sequence = [
  { ref = "format", passthrough=True }, # would look at "format" and reuse the definition of only the relevant args there
  { ref = "something_else", passthrough=False }, # same, without passing
  { ref = "yet_another" },
]

I think this non-verbose option is nicer for the user, because if 2 referenced tasks are trying to use an argument with the same name but different definitions, then the "all" task in my example does not care, and one of the referenced task will rightly complain. That makes it easier for the user.

[nat-n]

Thanks for the suggestion @guillaume-alliander

Working with your example, the solution I had in mind was as follows:

[tool.poe.tasks.all]
sequence = [ "format ${arg1:+ --arg1}",  "something_else ${arg2}",  "yet_another"]

Would you foresee any downside to this approach (which is a small change from what's already implemented).

[guillaume-alliander]

It seems to work for flags and positional arguments.

Would it work for named arguments (nested substitution?):

[tool.poe.tasks.all]
sequence = ["format ${arg1:+ --arg1 ${arg1}}"]
args=["arg1", ]

multiple positional (here ${arg1} should be a string, not a python array):

[tool.poe.tasks.all]
sequence = ["format ${arg1}"]
args=[{ name = "arg1", positional = false, multiple = true } ]

multiple named (no idea how to represent it :) ):

[tool.poe.tasks.all]
sequence = ["format ???"]
args=[{ name = "arg1", positional = true, multiple = true } ]

That is why, with the idea of passthrough there is no need to think about these syntaxes.
That said, I might not have a clear view of what is possible.

[nat-n]

Nested substitution should work, though I take you're point that it's not the simplest approach. I hadn't thought about that because I usually would have a sensible default value for args in this case so I can just always pass the value to the ref. Substituting a multi-value arg (whether positional or not) should also work by expanding to a space delimited list.

I plan to implement this anyway, since it's actually just a matter of making ref tasks consistent with how cmd tasks already work – which is itself a strict subset of bash syntax.

Pass arguments through is actually the default behaviour for ref tasks when defined at the top level, however it's a little more complex if they're defined inline in a sequence task, since it's the sequence task that decides how to call the ref task. I'm going to think about it some more and see if I can be convinced that it makes sense.

[guillaume-alliander]

Thanks for thinking about it! it looks like you have an idea about all hurdles I could think of :) and that all cases are covered, which is what would matter I guess.

Although I totally agree with sensible defaults, I would tend to want to define them in one place, and not twice (I mean that i would like to have them defined int the called taks, the caller (sequence) being as dumb as possible).