Open
Description
This will put you in a world of confusion:
class MyTask < LuckyCli::Task
arg :summary, "", optional: true
positional_arg :name, ""
def call(io : IO = STDOUT)
# do stuff
end
endMacro-generated args can easily conflict with the in-use internal namespace in the task infrastructure. When you run lucky -h with that task in your tasks directory, you'll get an opaque error because calling .name on the class isn't doing what lucky_cli thought it would do. You'll get:
Unhandled exception: name is required, but no value was passed. (Exception)
I wonder if it makes sense to:
- namespace the LuckyCli::Task infrastructure, for example instead of a
summarymethod being generated from thesummarymacro, maybe it generates a_task_summarymethod. - encapsulate the declared arguments within an Args object of some sort. Within a task, a
arg :summarywould be accessed viaargs.summaryinstead of justsummary. - simply warn the developer that they're about to shoot themselves in the foot by declaring an arg with a name of: name, summary, help_message, call, etc
Metadata
Metadata
Assignees
Labels
No labels