Helper modules within a dep source

[Paul Annesley]

Hey,

I'm trying to abstract some common helpers that are duplicated throughout a babushka dep source.

I figured I could implement them all as module methods, and then include that module into the dep source files, or via Babushka::DepDefiner.send(:include, ...).  However, I could see no elegant way to ensure the module (as an auto-loaded .rb file amongst the deps) is defined before attempting to include it.

Is there a better way to do this?  Some other way to have helper methods shared between deps / dep files?

Also, given accepts_value_for :blarg in a dep, could a helper method in a module reference blarg?

Cheers!

Paul

[Ben Hoskings]

On 12 January 2011 16:15, Paul Annesley <paul.a...@gmail.com> wrote:

Hey,

I'm trying to abstract some common helpers that are duplicated throughout a babushka dep source.

I figured I could implement them all as module methods, and then include that module into the dep source files, or via Babushka::DepDefiner.send(:include, ...).  However, I could see no elegant way to ensure the module (as an auto-loaded .rb file amongst the deps) is defined before attempting to include it.

Hmm. There's no explicit way to do this but there might be a neat way.

Could you stub out the kind of includes you'd like to do? Then I'll have a look at the best way to make it happen.

Also, given accepts_value_for :blarg in a dep, could a helper method in a module reference blarg?

Yep, that should be fine. The methods will be run in the correct binding so it all should line up.

Also bear in mind there are a few recent changes that affect this stuff.

Firstly, DepDefiner and DepRunner have been merged into a single class, DepContext. There was no reason to keep them separate, and it resulted in both confusion and a bunch of delegations between the two anyway.

Secondly, #helper is deprecated in favour of just defining methods. So where before you would say

    helper(:foo) { blah }

just do

    def foo() blah end

—Ben

[Paul Annesley]

G'day Ben,

Below is an example of these helper methods, and the way I hacked it
to work in Babushka 0.8.6... although Xavier Shay has to take some of
the blame :)

With the below module placed in
babushka-deps/helpers/apache-site-helpers.rb, the following line is
added to the top of any dep file which requires any of its helpers:

require File.expand_path("../helpers/apache-site-helpers", __FILE__)

Most of the helper methods are used extensively by a bunch of related
meta dep templates. So a dep could say "accepts_value_for :project"
and these helpers would combine that with the prompted organization
var to provide things like github_remote, site_hostname and lots more.

So.. my problem is worked around for the moment, and I imagine
adjusting it to use DepContext should be trivial. But it seems like
something that would be useful to any large repository of deps. It
could also help foster a collection of useful helpers like those in
run_helpers.rb, which I use a fair bit.

Cheers!
Paul

babushka-deps/helpers/apache-site-helpers.rb
####

module ApacheSiteHelpers

def organization
var :github_organization,
:message => "GitHub organization, e.g. learnable, 99designs",
:sticky => true
end

def organization_path
"/home/#{ENV['USER']}/#{organization}".p
end

def github_remote
"g...@github.com:#{organization}/#{project}.git"
end

def site_hostname
"%s.%s" % [project, `hostname -f`.chomp]
end

# plus lots more ...

end

Babushka::DepDefiner.send(:include, ApacheSiteHelpers)

####