Support variable-length arguments for Tasks

[dennisjbell]

As an alternative implementation to #70, this allows tasks to access parameters beyond the named parameters that are currently supported. This is accomplished by storing the sequential list of values provided as arguments to the task, and making them available to the block via args.extras.

I have encountered the need for iterating over a variable number of values in a task many times, such as this contrived example below:

desc "Send a message to one or more recipients"
task :email, [:message] do |t, args|
  mail = Mail.new(args.message)
  recipients = args.extras
  recipients.each do |target|
    mail.send_to(recipent)
  end
end

It remains compatible with the current named argument and prerequisites syntax using the arrow notation, and doesn't create any further auto-generated hash keys.

It also adds a to_a method to provide the full list of values passed in, regardless whether they are associated with a named argument or not.

[jimweirich]

This seems like a reasonable request and implementation. I'll probably hold off merging it until this current round of bug fixes are done on the 10.0.x series.

[sgonyea]

Definitely in favor of this feature. Thank you for creating this PR.

[jch]

👍 great work!

[JeanMertz]

Was just looking for this feature. Great to see it will be implemented soon(ish) 👍

Too bad I can't seem to use forks of Rake, seems the repository is missing some basic Rubygems file to make it work out of the box

[jimweirich]

I've merged this change into master.

[jimweirich]

"Too bad I can't seem to use forks of Rake, seems the repository is missing some basic Rubygems file to make it work out of the box" -- JeanMertz

Could you expand on this comment? What's missing?

[contentfree]

How can we pass argument values that contain commas? For example, I have a task that needs to receive a list of queues to watch (DelayedJob) and it expects a comma-separated string of names.

I suppose I could use arg.extras to recreate the original string passed in... Yeah?

[dennisjbell]

Yes, that should work. Put all your static args in the front (if you have any) then args.extras will contain an array of your queue names.

[JeanMertz]

@jimweirich

"Too bad I can't seem to use forks of Rake, seems the repository is missing some basic Rubygems file to make it work out of the box" -- JeanMertz

Could you expand on this comment? What's missing?

Not sure if this is still the case. But with these small (temporary) modifications, I like to:

• Fork the repo on GitHub
• Make the required changes through the GitHub online editor
• Update my Gemfile and add gem 'rake', github: 'JeanMertz/rake'

This works for most repositories, but yours seems to be lacking the required gemspec file to do this. I've had to create one for your rspec-given repository, as seen in JeanMertz/rspec-given@8acc7a6

It's no big problem, I just noticed this a while ago.

[jimweirich]

Jean: I purposely don't include a gemspec in the repo because individual commits are between versions. Any version given in a gemspec file will be a lie.

If you wish to use the repo as a gem source, I recommend:

• Use the ref:, branch: or tag: option to tie to a particular commit. Otherwise I could break your system with a single push to head.
• Supply your own manufactured version number that doesn't conflict with official release numbers.

For example:

gem 'rake', '10.1.0.beta.15c574bd', git: 'git://github.com/jimweirich/rake.git', ref: '15c574bd651d8553c89e1d9a01ab680d630ce626'

The above ties the gemfile to a particular commit in the repo and constructs a beta release number incorporating the hash reference.

[jimweirich]

Oh, and also rake-10.1.0.beta.3 is available for installation. Just include --pre on the gem install command to get it.