Is there an option to have aliases for tasks?

[mgzenitech]

The best I could come up with:

[tool.poe.tasks.mf]
help = "(alias) Merge multiple source files into a single destination file according to the specified file type."
ref = "merge_files"

[tool.poe.tasks.merge_files]
help = "Merge multiple source files into a single destination file according to the specified file type."
script = "cli.__pyhelpers.merge_files:merge_files"

But that just shows up as two different tasks in --help....

CONFIGURED TASKS
  mf                              (alias) Merge multiple source files into a single destination file according to the specified file type.
  merge_files                     Merge multiple source files into a single destination file according to the specified file type.

Maybe there is some way to show it as alternative name?

CONFIGURED TASKS
  mf, merge_files               Merge multiple source files into a single destination file according to the specified file type.

[nat-n]

Hi @mgzenitech,

Indeed ref tasks are the closest thing that's supported today.

It probably wouldn't be too complicated to add support for defining alternative names for tasks, though I'm not totally convinced about the value. If you want short task names then you can do that, and you can use help text to make it clear what the short names mean. If you like descriptive names but don't like typing then tab completion is available for most shells (anyone want to contribute tab completion for PowerShell?). And in a pinch you can make a ref task that is an alias of another task. Am I missing something?

[nat-n]

I see. In that case I would take this as a +1 for a previous feature request to be able to declare common sets of arguments globally and then reference them from tasks. Do you think that would be a good compromise?

Also Ref tasks actually do inherit the args from the original tasks in a sense, in that by default whatever arguments you pass to the ref task will be received by the original task, however I'm hesitant to make the ref automatically inherit the definition of the args, because this would complicate using ref tasks to alter the args passed to the source task which is a use case today.

For example:

[tool.poe.tasks.apologize]
cmd  = "echo \"Sorry ${name}, ${explain}\""
args = ["name", "explain"]

[tool.poe.tasks.sorry-dave]
ref  = "apologize --name=dave --explain=${explain}"
args = [{ name = "explain", positional = true }]

$ poe sorry-dave "I can't do that"
Poe => echo 'Sorry dave, '
Sorry dave, I can't do that

(I just realised there's a bug/missing feautre in ref task around passing arguments, so the above example won't fully work, but this is the intended behaviour)

[mgzenitech]

Erm, but if ref already automatically inherits everything from the referenced task, then why not just load task definition from there? I mean since it already does that maybe it would be wise to actually also display it automatically? Technically ref allows preprocessing before downstream task, so maybe it would be better to do it automatically with ability to override?

For example:

[tool.poe.tasks.apologize]
help = "I will be shown only for sincere apology task"
cmd  = "echo \"Sorry ${name}, ${explain}\""
args = ["name", "explain"]

[tool.poe.tasks.sorry-dave]
ref  = "apologize --name=dave --explain=${explain}"
args = [{ name = "explain", positional = true }]

[tool.poe.tasks.sorry-dave-not]
ref  = "sorry-dave --explain=NOT"
help = "Will be shown instead of referenced `apologize` task help"

[mgzenitech]

or even bool inherit = true or something similar for ref task

[nat-n]

Your feedback has prompted me to realise that the ref task doesn't quite conform to my own intuitive expectations around handling arguments. So I've embarked on a minor refactor to improve this, which I think will help with your use case. I'll report back here when I have something

[nat-n]

hey @mgzenitech, I just pushed an update that makes ref handle parsing and passing arguments as discussed. https://github.com/nat-n/poethepoet/releases/tag/v0.25.0

I think your idea of making ref tasks explicitly behave like aliases (e.g. inheriting args in the docs) if both tasks are visible and defined at the top level and the ref has no help or args defined. Although this will be a little tricky to implement given that tasks currently aren't involved in generating docs. I'll have a look after the current refactor I'm doing with config.

At least now ref tasks will behave like aliases at runtime.