If you have the time, I certainly think you're the right one to implement this, Gabe. You've got the real-world need, which is the mother of invention. :)

Regarding fetch_or_default, what if it was just an option to fetch() that determined whether or not the variable was set to the default or not? Something like:

foo = fetch(:bar, "hello") # returns bar or "hello", but does not change bar foo = fetch(:bar, "hello", :set => true) # sets bar to "hello" if bar is not set

It does break the Hash-like API, but then, so would fetch_or_default, so I think it's fair. In general, I prefer to minimize the number of API calls that people would need to know, in favor of generalizing a single interface. It's the same philosophy behind ActiveRecord's "find" method, which used to be "find_all", "find_first", and so forth, and was later combined into the single "find".

Thanks for the offer to work on this, Gabe! I think, for me, the biggest win is the automated documentation generation, which really doesn't even depend on the variable dependencies being documented. :) At any rate, bring it on!

- Jamis

On May 14, 2008, at 11:07 PM, gabe wrote:


Also, I meant to offer to help make any of the changes, just let me
know.. since forking is the new friending these days.

On May 15, 12:58 am, gabe <[EMAIL PROTECTED]> wrote:
Yeah I like that alot. Yeah arg or argument is definitely not the
right word.. Maybe "variable" or "ref" or "var" are options too.

I think this even works (although just because you can doesn't mean
you should):

desc(<<-DESC) do |d|
  Here is my description...

  DESC
  d.references :rake, "Path to rake", :default => "rake"
end

I also had the case where I wanted the default to be the value of
another variable (so you could override it, or fall back to another
variable).

  d.references :sphinx_db_name, "Name of sphinx db", :set => :db_name

which I guess was shorthand for :default => Proc.new
{ fetch(:db_name) }. Although as long as we are in the desc block we
wouldn't need the Proc wrapper and so... I guess just a use (or edge)
case to be aware of.

Another thing I monkey patched, was to support a fetch_or_default
method which set the variable to the default if it wasn't set (as
opposed to returning a default value for that call only)... If that
makes sense.

--gabe

On May 14, 5:10 pm, Jamis Buck <[EMAIL PROTECTED]> wrote:

That's a neat idea (and I LOVE the autogenerated documentation!), but I'm not sure I like adding (1) another "keyword", and (2) calling them arguments, when they're really just variables that the task depends on.

What if this was implemented by extending the 'desc' keyword,
something like this:

   desc do |d|
     d.text "foo"
     d.references :rake, "Path to rake", :default => "rake"
     # ...
   end

The original syntax would continue to work, too:

   desc "foo"

This way, we could later decide that we want to document other aspects
of the task (roles, subtasks it calls, etc.) without resorting to
further cluttering the namespace. What do you think?

- Jamis

On May 14, 2008, at 2:29 PM, gabe wrote:

In the capitate gem, we added a task_arg metho to the task DSL, so
that we could document and setup defaults for cap variables.

For example,

---

 desc <<-DESC
   Run the migrate rake task ....
 DESC
 task_arg(:rake, "Path to rake", :default => "rake")
 task_arg(:merb_env, "Merb environment", :default => "")
 task_arg(:migrate_target, "Migration target", :default => :latest)
 task :migrate, :roles => :db, :only => { :primary => true } do

   current_directory = case migrate_target.to_sym
     when :current then current_path
     when :latest  then current_release
     else raise ArgumentError, "unknown migration target
#{migrate_target.inspect}"
     end

   run "cd #{current_directory}; #{rake} MERB_ENV=#{merb_env}
#{migrate_env} db:migrate"
 end

---

http://github.com/gabriel/capitate/tree/master/lib/recipes/merb.rb

Using this info, we also generate documentation, for example:
http://capitate.rubyforge.org/recipes/merb.html

Is this a weird "extension" of cap or do you think its something that
might be useful to add in?

Thanks!

 smime.p7s
3KDownload
--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to