The depressing world of RoR

*This is a rant so you have to take it with a grain of salt; on the other hand, what I’m going to write about is not just my emotional status working with Rails, and you should not take it like it was coming from a Ruby or Rails either; Ruby is still my language of choice, and the blog is still running on Typo, after all.*

After announcing ruby-ng in development, I’ve proceeded with expanding the testbed. While it’s a huge amount of work, and is not supposed to be the final version of the ebuilds that will enter portage, I think that it’s a very good idea to actually test it with real-world situation. One of the most common mistakes with eclasses (and I’m just as culprit of that) is to design them with what you think you should need; which almost never is the same of what you actually will need.

So anyway, the next obvious step was to convert out of gem something that was, before this, pretty impossible: Rails and its dependencies. The main advantage of getting Rails installed manually rather than through gem is that the tests can be executed, so you can make sure the code you’re going to install is fine. If the tests work.

The first problem I came to is that, stupid me for not knowing, activesupport bundles some gems (they coined the term “vendorizing” but it’s just bundling, and it’s just as well ); of these four (builder, i18n, memcache-client and tzinfo) one was already ported to the overlay as the second main testcase (tzinfo), one I knew about and had some trouble with it before (memcache-client: no tarball in releases, Subversion as SCM, no tags for versions!), one was in both tree and overlay (builder), and one I never heard about.

While removing tzinfo was trivial (given that the ebuild seems to work pretty fine and is also updated), the remaining three have been giving me headaches; as I said memcache-client does not have an easy way to install as non-gem; at the same time, builder’s tests don’t pass on Ruby 1.9, not even after changing the code from 2.1.2 release with the one shipped within activesupport (which, by the way, is just one sourcecode line different, all the remaining differences are whitespace and typo fix in comments!); it’s likely that the testsuite is broken rather than builder, but still, it’s not strictly amusing.

But what drove me off to bed last night was actually i18n : the website looks pretty uninteresting, just a single “blog-like” post from last summer, and links to the two gems (for ruby and rails) with their trackers, and the mailing list. The link to the i18n gem’s repository also say “will be moved”.. where to? No idea. There is no download link, since they assume you’re going to get it through gem; the GitHub page does not provide any download either, nor it provides any tag at all, which is even worse than last time .

So okay, let’s leave memcache-info and i18n alone for now and let’s also ignore the builder’s test failure.. activesupport has no testsuite! So I can’t even be sure that it does load the standalone tzinfo properly until I finish and put something up that runs on the new Rails; okay not tremendously important at this point, let’s go on with the rest of the Rails dependencies. Again no test for activerecord since it needs a database (it should be testable with sqlite3 but since I remember having problem with that particular ebuild’s testcase before, I haven’t ported that yet), nothing I can blame them for there.

The problem resumes with actionpack: it requires (or at least tries to) actionmailer when running the tests, but actionmailer depends on actionpack; so you cannot test them the first time around, you got to build them without test first and then you can enable the tests.. and I haven’t been able to test these yet because, as usual, actionmailer has two bundled libraries (text-format and tmail) that I want to get rid of (text-format is present and ported, tmail not present, not even in Portage).

This starts to get even longer than I expected.