You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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 -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:
summary
method being generated from thesummary
macro, maybe it generates a_task_summary
method.arg :summary
would be accessed viaargs.summary
instead of justsummary
.The text was updated successfully, but these errors were encountered: