Jerry, Thanks for a really well-thought-through post, I'll need to have a think in a bit more detail; you are absolutely right, we are due some serious consideration about our architecture; to that end I would prefer to leverage the power rake gives us, but Vlad is like playing in a sandpit when you should be at work!
I'd be really pleased to entertain your ideas on IRC, catch me in #capistrano on freenode if you're into IRC and we can talk about it a little. -- Lee Hambley Twitter: @leehambley Blog: http://lee.hambley.name/ Working with Rails: http://is.gd/1s5W1 2009/8/26 jerry.vos <[email protected]> > > In building out some complex deployments, I seem to continually have > the need to have helper methods for my tasks. The way I've done it and > the way I see capistrano-ext does this, is to just define the helpers > alongside your task definitions: > > Capistrano::Configuration.instance(:must_exist).load do > def something_interesting; end > end > > This works fine and all, but I have the same problem with this that I > have with doing this in rake tasks, that is, there is no scoping to > these method definitions. This is worse in rake tasks, since doing > this in a rake task defines the method on Object, but it still feels > bad to me. The practical problem I've found is it makes it hard to > track down where those methods are defined. > > My way of solving this with rake tasks (and others like rSpec seem to > solve this) is by having subclasses of Rake::Task. I looked into doing > this for capistrano, and I think it would just mean a little > refactoring around the Capistrano::Configuration::Namespaces#task > method. Before diving into this though, I wanted to see if anyone sees > any downside to this or if there's some other common pattern to this > I'm missing. > > You could also define helper classes and put the methods in there, but > often you need access to the run/sudo/... functionality which would > require injecting capistrano classes into the helpers. I'm not sure if > that seems semi-elegant or semi-clunky, but I still feel that it > should be solved with a custom TaskDefinition. It does seem flexible, > but that the usage would be complicated. > > For conversation's sake, an example: > Capistrano::Configuration.instance(:must_exist).load do > namespace :data do > desc "Verifies that the data version is as expected" > task :verify_version => :environment, :roles => :db do > run_rake("data:verify_version") > end > end > > def run_rake(*args); run(build_rake_command(*args)); end > def system_rake(*args); system(build_rake_command(*args)); end > def sudo_rake(*args); sudo(build_rake_command(*args)); end > end > > I'd want to implement those methods as: > module Capistrano > class RakeTaskDefinition > def (run,system,sudo)_rake.... > end > > def rake_task(*args) > RakeTaskDefinition.define_task(*args) > end > end > > Capistrano::Configuration.instance(:must_exist).load do > namespace :data do > desc "Verifies that the data version is as expected" > rake_task :verify_version => :environment, :roles => :db do > run_rake("data:verify_version") > end > end > end > > Truthfully, the other reason I'm asking this instead of coding it is > it seems like this is another one of those things Rake already does, > so it's again making me wonder why not just spend the time making cap > tasks be based on Rake (ala Vlad, but without trimming cap's > functionality), but that's a much bigger topic. > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Capistrano" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.co.uk/group/capistrano?hl=en -~----------~----~----~----~------~----~------~--~---
