I have a branch with the patches at: http://github.com/gabriel/capistrano/commits/desc_enhancement_clean
First commit adds :set option to fetch: http://github.com/gabriel/capistrano/commit/6ac6bdb0e030af1286c010669cfa0276f2f38209 Second commit adds block enhancement to desc keyword: http://github.com/gabriel/capistrano/commit/d2ca02980d11d7247cdf27665cec2dffab1e9bd6 An example of the use of the desc enhancement: -- namespace :merb do desc <<-DESC do |d| Run the migrate rake task. By default, it runs this in most recently deployed version of the app. However, you can specify a different release via the migrate_target variable, which must be one of :latest (for the default behavior), or :current (for the release indicated by the `current' symlink). Strings will work for those values instead of symbols, too. You can also specify additional environment variables to pass to rake via the migrate_env variable. Finally, you can specify the full path to the rake executable by setting the rake variable. DESC d.reference(:rake, "Path to rake", :default => "rake") d.reference(:merb_env, "Merb environment", :default => "production") d.reference(:migrate_target, "Migration target", :default => :latest) d.reference(:migrate_env, "Migration env", :default => "") end 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 end -- There is a potential incompatibility with the TaskDefinition desc attribute, which now returns a Capsistrano::Description object instead of a String. I'm not sure how public this desc attribute is mean to be. The description method still returns a String :) ... It is possible to keep the desc as a string and create another attribute for the description object. Let me know if you'd rather take that route. Another (maybe) non-obvious thing is that the desc block is not called until right before the task execution. Everything else should be obvious. :) On May 15, 12:12 pm, gabe <[EMAIL PROTECTED]> wrote: > yeah the :set is way better.. :) > > On 15 May, 10:21, Jamis Buck <[EMAIL PROTECTED]> wrote: > > > 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 > > > 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 -~----------~----~----~----~------~----~------~--~---
