While we’re definitely not yet done with translating ebuilds to the Ruby-NG eclasses (ruby-ng proper and ruby-fakegem have been joined by ruby-ng-gnome2 that Hans implemented to replace the older ruby-gnome2, that used the old eclasses), we’re coming to a point where the amount of knowledge we’re amassing from dealing with common troubles in Ruby packages can be very important to other developers. I have widely ranted about the amount of trouble we’re going through for tests to work properly and stuff on those lines, but as I’ve been noted, I haven’t given much information on how to solve the problems. I’ve decided to try solving that now.
I have to say first of all that running tests is definitely quite important to find eventual latent issues, so we’re trying our bests to run them whenever it’s possible, also thanks to the help of arch team members, starting from Brent (rangerpb) that has spent the past two days keywording ~ppc64 the Ruby packages that had dropped keywords with the port to the new eclasses (because of newly introduced dependency). Not only he reported some missing dependencies (when you already have a long list of gems installed, it gets difficult to identify eventual other needed gems, especially when they are not listed in the gemspec, as I already noted), but also found one very nasty issue in RedCloth for PPC and PPC64 systems (where char is unsigned by default), thanks to the testsuite that can, now, be executed (on the other hand, 4.2.2 with the old system was already keyworded, and yet it couldn’t work properly, so that shows how it is easy to ignore problems when you don’t have testsuites to run).
Anyway, first in a list of possible Ruby solutions to problem we’re hitting, I’d like to propose the problem of the varying implementation of a testsuite. While there are many different frameworks for running tests on Ruby, that is not what I’m trying to get your attention drawn to. Instead, think of the way you can actually call the (for the sake of argument) test-unit testsuites from a Rakefile.
The rough way consists of just requiring all the files with a given name inside the test directory; this is what the original fakefs gem does:
$LOAD_PATH.unshift File.join(File.dirname(__FILE__), 'test')
desc "Run tests"
task :test do
Dir['test/**/*_test.rb'].each { |file| require file }
end
This does not seem to work properly with either test-unit-2 installed for Ruby 1.8, or with JRuby 1.4.0 (at least). I guess this relies on the ability, for the test runner, to automatically pick up the test objects.
The nasty way is to call the testrb command, that invokes the test runner “properly”. I say it this way because the problem here is that a Rakefile that invokes testrb will ignore the currently-running Ruby version, and will fire up the default Ruby implementation selected (I reported of a similar problem with specrb before):
# Flameeyes's note: this code comes from amatch, so it's very real.
desc "Run unit tests"
task :test => :compile_ext do
sh %{testrb -Iext:lib tests/test_*.rb}
end
The correct way is even easier! Just rely on rake to do the right thing for you if you use it properly!
require 'rake/testtask'
Rake::TestTask.new do |t|
t.libs << [ "ext", "lib", "tests" ]
t.test_files = FileList["tests/test_*.rb"]
end
In this case, rake will take care of setting up Ruby exactly as it’s needed, testing using the same version of Ruby that has started the Rakefile in the first place. And it standardises a lot more the Rakefile.
I’m going to send this change to amatch exactly as I did for fakefs, but there are most likely more cases of that out there. If you find one, please fix it, so that we’re not going to hit more bumps down the road. Thanks!
And for those interested, my GitHub page lists some of the packages for which I submitted patches and fixes, some are related to packaging entirely, others are Ruby 1.9 or JRuby related. You can see that I don’t stop at ranting but I actually write code to tackle the issues.
