Rakeforms

[T. Onoma]

I sent off an email too "Jim Weirich" <[email protected]> but I'm not sure
if he (you) got it. So I thought I just post here.

I was using a certain rakefile a lot so I modified it to read a yaml file for
its needed parameters. It seem pretty useful in general so I though other
might like it,or like to improve on it (it's for package management and
development stuff), so I put in with rake itself and modified rak to check
for a Rake.yaml file if no Rakefile was found. The Rake.yaml file specifies
which Rakeform to use and it goes form there.

Does that sound useful to anyone else. Are there other common template
"Rakeforms" people might contribute?

 

[Jim Weirich]

I sent off an email too "Jim Weirich" <[email protected]> but I'm not sure
if he (you) got it. So I thought I just post here.

I did get it ... thoughts below ...

I was using a certain rakefile a lot so I modified it to read a yaml file for
its needed parameters. It seem pretty useful in general so I though other
might like it,or like to improve on it (it's for package management and
development stuff), so I put in with rake itself and modified rak to check
for a Rake.yaml file if no Rakefile was found. The Rake.yaml file specifies
which Rakeform to use and it goes form there.

Could you provide a specific example of how you use this? In many ways,
a Rakefile is a configuration file for building software, and I'm a
little hesitant to add a config file for a config file unless there are
compelling reasons.

 

[Alexey Verkhovsky]

Could you provide a specific example of how you use this? In many ways,
a Rakefile is a configuration file for building software, and I'm a
little hesitant to add a config file for a config file unless there are
compelling reasons.

Same reason that most Ant buildfiles have <properties
file="override.properties"/> construct, I presume.

Development environments have individual characteristics (most often,
database connection attributes, I've also seen port numbers, paths,
CVSROOT values, HTTP proxy settings etc). So, you use named variables in
the build file (which is in CVS), and specify their values in a separate
file (which is in .cvsignore).

I use eval('build.properties'), where build.properties is a bunch of
FOO=bar assignments.

Alex

 

[T. Onoma]

I did get it ... thoughts below ...

There you are!

Could you provide a specific example of how you use this? In many ways,
a Rakefile is a configuration file for building software, and I'm a
little hesitant to add a config file for a config file unless there are
compelling reasons.

Understandable.

The idea was simply to have common rakefiles easily reusable via YAML config
--which are easier to read, write, etc. But yes, another level of
indirection.

The idea was that people could share highly useful/common "rakeforms". They
rakefiles, which in turn are Ruby programs after all, just very high level.
But they provide an easy way to fill out the open variables in the special
rakefile. I don't know if something like this is really all that commonly
useful or not. Just thought I suggest it and see if others had any ideas. As
for me I have the one rakeform which does gem creation, rdoc generation,
manual install, etc. Very useful, and surely useful to others as well. Using
a YAML file to fill out the common variables is just neater/simpler, and then
the rakefile itself is generic, so it can be shared. That's all.

 

[T. Onoma]

Could you provide a specific example of how you use this?

Not sure what you mean, but here's a very basic example.

BTW, it doesn't seem like there is much demand for such a feature built
directly into rake. Not that it's a bad idea of anything, but unless you have
a keen interest otherwise, I'll just withdraw my proposal.


# RAKE.YAML ----------------------------------------------------
# tests
PKG_TEST_DIR: test
PKG_TEST_FILES:
- 'test/*_test.rb'
- 'test/**/*_test.rb'


# RAKEFORM -----------------------------------------------------
require 'rake'
require 'rake/testtask'

#################################################
# load config from Rake.yaml and make constants #
#################################################
YAML::load( File.open('Rake.yaml') ).each{|c,v| self.class.const_set(c,v)}

##
# = Default Task
##
desc "Default Task (test)"
task :default => [ :test ]

##
# = Run Unit Tests
##
Rake::TestTask.new("test") { |t|
#t.desc "Run all tests"
t.libs << PKG_TEST_DIR
PKG_TEST_FILES.each { |pat| t.pattern = pat }
t.verbose = true
}

 

[Jim Weirich]

T. Onoma said:

BTW, it doesn't seem like there is much demand for such a feature built
directly into rake. Not that it's a bad idea of anything, but unless you
have a keen interest otherwise, I'll just withdraw my proposal.

Thanks for the proposal. I always like feedback ... I'm just trying to
understand the utility of what you suggest.

Why not just do this ...

# RakeSetup.rb -------------------------------------------------
PKG_TEST_DIR = "test"
PKG_TEST_FILES = ['test/*_test.rb', 'test/**/*_test.rb']

# Rakefile -----------------------------------------------------
require 'rake/testtask'
require 'RakeSetup'

##
# = Default Task
##
desc "Default Task (test)"
task :default => [ :test ]

##
# = Run Unit Tests
##
Rake::TestTask.new("test") { |t|
#t.desc "Run all tests"
t.libs << PKG_TEST_DIR
PKG_TEST_FILES.each { |pat| t.pattern = pat }
t.verbose = true
}

-----------------------------------------------------------------

Isn't the above functionally the same as the Yaml version, but without
introducing yet another library.

(BTW, I know this is just an example, but assigning the pattern field
twice won't do what you think. The only reason this works is that the
second patterns matches all the files (and more) that the first pattern
matches.)

(Not quite a rant, but some pointed observations about tools below)

Rake is unusual in that if you know Make (and to a lesser degree, ant),
you can transfer that knowledge to Rake fairly easily. Mostly its just a
change in the syntax. However, Rake does not suffer the same limitations
as Make, and things you did in make to get around some of those
limitations are not needed in Rake. I find this to be intuitively true,
but difficult to communicate to those who haven't used Rake.

A good example comes from an question I received this past week. Someone
had to run Rake under two different environments and the dependencies in
each environment were different. The question was how can one declare
dependencies.

The key to answering the problem is to remember that a Rakefile is a full
powered Ruby program and that task declarations are nothing more than
method calls. The simple answer was:

task :doit do
# Common actions for task doit
end

if in_environment_a?
task :doit => [:dependencies_in_environment_a]
else
task :doit => [:dependencies_in_environment_b]
end

Just as Dijkstra observed "A Programming Language is a tool that has
profound influence on our thinking habits", so do the tool we choose.