Feature Request: Custom rake task name about oops_a_rake HOT 7 CLOSED

Might as well make it accept options like dry-types:
https://dry-rb.org/gems/dry-types/1.2/getting-started/

  include OopsARake::Task(
    name: "custom_name",
  )

Their implementation looks like:
https://github.com/dry-rb/dry-types/blob/v1.4.0/lib/dry/types.rb#L201-L203

from oops_a_rake.

I've just released version 0.2.0 which supports custom task names. Thanks for the suggestion & feedback @PikachuEXE

from oops_a_rake.

Hi @PikachuEXE,

I like this suggestion, it makes a lot of sense.

Unfortunately adding this feature is quite complicated under the current implementation. At the moment the task is registered immediately when the OopsARake::Task module is included:

Originally I thought we could just rename the Rake task if #name is called, but Rake doesn't seem to have a public API for renaming tasks (it seems possible by accessing instance variables, but I'd rather avoid that).

To support this feature I think we'd have to defer registration of Rake tasks until a hook is called, similar to this in the Rakefile:

# Rakefile

require "oops_a_rake"

# Optional config
OopsARake.task_paths = ["lib/tasks/*.rb"]

OopsARake.load_tasks

I think this more explicit loading mechanism is probably a better design, similar to FactoryBot.find_definitions.

I can take a look at adding this over the weekend. Ay feedback on the proposed changes would be welcome!

from oops_a_rake.

Or something like this (but not sure if can be done):

class GreetingTask
  include OopsARake::Task::Lazy

  register do |task|
    #not calling `name` = generate name from class
    task.name "say_hello"
    task.description "An enthusiastic greeting"
    # other config
  end

  def call
    puts "Hello!"
  end
end

from oops_a_rake.

@PikachuEXE I've made a PR proposing a solution like this:

class ObscureClassNameTask do
  include OopsARake::Task.with_name("custom_name")
  
  def call
    puts "Hello"
  end
end

Would this work for you?

from oops_a_rake.

I don't think that'll work in this case unless I'm missing something. Mimicking the self.Types method from dry-types would mean that'd including the module would be include OopsARake.Task rather than include OopsARake::Task, which seems weird to me.

My preference would be to not compromise the base use case to support this feature. I'd suggest a halfway house which is more flexible than ::with_name for future use cases:

include OopsARake::Task.with_options(name: "custom_name")

from oops_a_rake.

As long as it's flexible enough I am fine with it

from oops_a_rake.