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
-~----------~----~----~----~------~----~------~--~---
