Somebody's gotta ask the obvious question... Why would you want to?
Really, I'm curious.
My goal is not just to make trouble, nor do I just want to have more toys
than anybody else. (Tho the idea does appeal to me....)
I'm trying to test RubyLexer. Part of RubyLexer's tests include a script
that can dertermine (not certainly, but with a high degree of accuracy)
whether RubyLexer is lexing a particular piece of source code in exactly
the same way as ruby itself. I've run this script (and fixed the problems
it found) against every bit of ruby source I could find on my system, and
now I'm looking for more.
I want to make a parser as well, and I'll need to test that. I think
there's a variation of my current test strategy that will tell me, for an
arbitrary source file, whether it has been parsed correctly.
Basically, rubygems will all be a sort of ad-hoc language test suite.
This is the sort of thing that's very easy in Debian. That's how I got all
Debian packages that depend on ruby, which form part of my collection
already. I don't know the reason, maybe because there's more qc of
packages upfront, or because apt checks for problems before even
downloading, or because installation of one package doesn't abort the
whole process. But handing off a long list of packages, some of which are
bad or broken, to apt-get works very smoothly. Not so with rubygems. I
realize Debian is a much more mature system... I'm really just looking for
a workaround. If a package is too broken to install, I don't want it.
Maybe there's someone out there with lots of gems already installed who
can give me a list of non-broken packages?
