Wow that example totally got mangled, here is a pastie: http://pastie.caboo.se/197828
On May 15, 5:06 pm, gabe <[EMAIL PROTECTED]> wrote: > 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/6ac6bdb0e030af1286c010669... > > Second commit adds block enhancement to desc > keyword:http://github.com/gabriel/capistrano/commit/d2ca02980d11d7247cdf27665... > > 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 -~----------~----~----~----~------~----~------~--~---
