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
end
Macro-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
summary method being generated from the summary macro, maybe it generates a _task_summary method.
- encapsulate the declared arguments within an Args object of some sort. Within a task, a
arg :summary would be accessed via args.summary instead of just summary.
- 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
This will put you in a world of confusion:
Macro-generated args can easily conflict with the in-use internal namespace in the task infrastructure. When you run
lucky -hwith that task in your tasks directory, you'll get an opaque error because calling.nameon 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:
summarymethod being generated from thesummarymacro, maybe it generates a_task_summarymethod.arg :summarywould be accessed viaargs.summaryinstead of justsummary.