Project:Ruby/Ongoing Tasks
There are a number of tasks that are currently being undertaken by the Ruby team. If you're an user or a developer interested in helping out, most of these have been started already and should be easy to get into them.
Porting to Ruby-NG and Ruby-FakeGem
The ruby-ng and ruby-fakegem eclasses form the basis of the modern RubyGems packaging in Gentoo Linux. The previous eclasses (ruby and gem) are now deprecated, but there are many packages still using them.
Of these packages, some are using Ruby as an interpreter, which is a feature that we haven't worked on just yet. This is something where we need some help to design an effective solution.
For the remaining packages, it's a matter of either removing them from the tree or write new ebuilds to use the new eclasses. Given that these packages have not been updated in the past few years, it might not be worth porting them unless there is a clear need for them.
Fixing remaining old-style ruby_add_[br]depend
The original implementation of ruby_add_bdepend and ruby_add_rdepend was extremely clumsy and required to pass two parameters: one with the list of USE flags under which the dependency should have been added, and another one with the list of dependencies.
Nowadays the functions take the same syntax as the main variables, but in some places the older version is still being used. Removing those uses will improve the general readability of the tree.
Porting to EAPI 4
The eclasses have been written to support EAPI 2 and later, as these versions support USE dependencies which are a requisite of proper multi-target ebuilds. It would be better, though, if all the ebuilds using the new eclasses were ported to EAPI 4, as that version defines REQUIRED_USE which ensures that there is at least one valid target enabled for that single ebuild during dependency calculation, instead than in the middle of the build process.
Porting to EAPI 4 is almost straight; there is one thing that needs to be fixed in ebuilds though: since runtime-generated ${S} values are no longer allowed, ebuilds making use of ruby-fakegem.eclass GitHub custom cases need to be converted to use RUBY_S instead, along these lines:
RUBY_S="${GITHUB_USER}-${PN}-*"
Once all in-tree ebuilds have been converted to EAPI 4, we can add a deprecation warning for those using older versions with our eclasses.
Porting to test recipes and helpers
Starting July 2012, after blog post by Flameeyes, ruby-fakegem.eclass supports so-called "receipes" for testing gems, while ruby-ng.eclass provides helper to simplify and standardise use of testing frameworks. See the how-to for more details.
Using the recipes allows for reduced test dependencies (removes the need for middleware such as Hoe as well as for Rake itself), and using the helpers means that their behaviour is consistent (default builds are coloured and quiet, showing progress dots only, while allowing users to receive verbose output and/or non-coloured output).
Right now the available recipes and helpers are:
- ruby-ng_rspec (available as RUBY_FAKEGEM_RECIPE_TEST=rspec);
- ruby-ng_cucumber (available as RUBY_FAKEGEM_RECIPE_TEST=cucumber);
- ruby-ng_testrb-2 (no recipe available).
Port to modern testing frameworks
Many of the issues we encounter with testing packages on Ruby implementations different from Ruby 1.8 is that the testing framework has changed enough that the previous syntax is no longer valid. A good way to work around this is to to make sure that we use a more modern testing framework.
In the case of tests based off Test::Unit, it should be relatively easy to force them to run through Test::Unit 2 via the ruby-ng_testrb-2 helper; for most (but not all) the packages that used the previous Test::Unit framework this will work correctly. This should also work with some, but definitely not all, tests suites based off Minitest.
While RSpec 1 does not seem to have different behaviour depending on the implementation, it still is an obsolete framework. For most packages the porting to RSpec 2 is trivial, and is thus suggested, if possible, to use the ruby-ng_rspec helper to execute the testsuite with the new version instead.
Renaming ebuilds to match upstream naming
For a while we considered re-generating the gemspec files depending on the resolved dependencies of the ebuild, to fix optional (USE-based) dependencies, and to remove the need to depend on build-time-only dependencies (what RubyGems call development dependencies). Unfortunately to do this, we first have to make sure we can match the package names with the RubyGems names.
As it is, at the moment of writing, there is no guarantee that gem name and package name actually match, as many ebuilds have been renamed to avoid collisions with other non-Ruby packages or because upstream renamed them at some point and now they no longer match.
Starting on 2012-08-15, Flameeyes started to rename the packages so that they match, but there are many still that require to be renamed. A batch of renames take a non-trivial amount of work and time to perform.