Tasks aren't executed within the scope of their task definition, which
means adding methods to TaskDefinition won't help you (the new methods
won't be accessible to the task). Tasks are added to the current
namespace instance, which is also where custom methods are added.
Thus:
task :foo do
run_something
end
def run_something
end
Both the :foo task and the run_something method exist side-by-side on
the top-level Capistrano::Configuration instance, and if you do:
namespace :bar do
task :foo do
end
def run_something
end
end
Both :foo and run_something exist side-by-side in the :bar namespace.
It's all very non-pollutionary.
- Jamis
On Wed, Aug 26, 2009 at 7:48 AM, jerry.vos<[email protected]> wrote:
>
> 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
-~----------~----~----~----~------~----~------~--~---
