Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Task DSL for arg and positional_arg should warn about naming collisions #4

Open
robacarp opened this issue Dec 3, 2020 · 1 comment

Comments

@robacarp
Copy link

robacarp commented Dec 3, 2020

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
@jwoertink
Copy link
Member

raise "🦶  🔫 "

Yeah, good call on that. I'm not sure the best route is just yet, but it would make sense that you might use those names, and they'd conflict.

@jwoertink jwoertink transferred this issue from luckyframework/lucky_cli Oct 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants