The Ruby Standard Library To Be Converted to Gems for Ruby 2.0?
The Ruby standard library (a.k.a. stdlib) is a collection of Ruby libraries that, at one time or another, have been considered useful enough to include with the MRI Ruby implementation by standard. Due to the popularity of these libraries, other Ruby implementations have then tended to re-implement or include the standard library too.
As part of the march toward Ruby 2.0, the state of Ruby's 'standard library' has come up for discussion. A popular line of thinking (and IMHO, very likely to actually happen) is that the standard library should be 'gemified' for Ruby 2.0.
Why Gemify the Standard Library?
The standard library approach has a significant flaw. Due to being a large and critical piece of software, MRI's release cycle is slow, yet some libraries require faster updates, perhaps for security or API updates. It would be better, therefore, to have the standard libraries maintained and distributed separately while still being included 'by default' with Ruby implementations.
We have already seen this sort of approach with RubyGems itself. For example, RubyGems is (at the time of writing) at version 1.8.11, yet the barely 2 week old Ruby 1.9.3p0 comes with RubyGems 1.8.10. While RubyGems is not itself distributed as a gem, it demonstrates the value of having something included with Ruby and still updateable separately.
Aaron Patterson (of the MRI Ruby Core Team) Explains
In his talk at RubyKaigi, Aaron tenderlove Patterson spoke about working out which parts of Ruby are 'third party libraries' and how to extract them. After such extraction, Ruby core should be able to commit to or change anything within MRI, but also reference third party gems that are included and installed by default on new installations. Aaron noted that being able to 'iterate faster' was a significant benefit of this approach.
Aaron also explained that with less coupling between Ruby implementations and the libraries they depend upon, it could be possible in future to upgrade your Ruby interpreter while still maintaining existing versions of the libraries you depend upon. This could help you migrate more gradually or merely help you maintain existing compatibility.
Further Reading
The process of gemifying the Ruby standard library is explained on the Ruby implementation wiki with the proposal, implementation, and a list of to do items already laid out. A more extensive discussion (which you can join) is also taking place on the official MRI Ruby issue tracker.
This process is still in its early stages and there are likely to be opportunities to help maintain or even become the maintainer for certain standard libraries, if you want to get involved.
November 7, 2011 at 5:38 pm
Congrats, you've discovered dual-life modules!
November 7, 2011 at 8:23 pm
We shouldn't do this until Ruby has a better packaging system than RubyGems. As it is, RubyGems is an embarrassment.
November 7, 2011 at 10:09 pm
November 7, 2011 at 10:09 pm
Can we add Fiddle (http://rubydoc.info/stdlib/fiddle/1.9.3/frames) to the list? Fiddle was added in 1.9, even though DL and FFI already existed. DL could also be moved out, since it is a UNIX specific API (Windows has no dlopen).
November 8, 2011 at 12:18 pm
Believe me, Peter, if I thought I could at this point I would. But just because I can't doesn't mean that my point isn't valid, and that this might not be a good idea.
November 8, 2011 at 2:59 pm
Mike, there is already an alternative to Rubygems called RPG (https://github.com/rtomayko/rpg).
November 8, 2011 at 3:34 pm
Haha, I wasn't actually responding to you Mike! :-) Sorry about that, I see how it looked that way.
I posted it based on a discussion on IRC I was involved with which implied that a more sinister motive for this re-architecture is so that "someone else" can deal with the supposedly crufty libraries rather than core ;-)
In terms of needing a better packaging system than RubyGems, I disagree, but don't have enough to say on the matter to discuss it in any interesting way. At the very least, I believe RubyGems should be the better RubyGems, not something else.
November 14, 2011 at 10:30 am
In theory this is a great idea; in practice I'm not sure... We could end up with a versioning nightmare where you need different versions of gems for different patch levels of Ruby e.g. Want to use CSV 1.1? for that you need Ruby 1.9.3p120 but it wont work with 1.9.3p115.
I can definitely see the bright-side though in that it makes Ruby-core a bit more nimble and we may well see a lot more collaboration (& competition) for the standard lib gems.
December 27, 2011 at 4:16 am
I think there is a misunderstanding here about exactly what a stdlib is supposed to be. It is actually not supposed to be "nimble and dynamic". It is in fact supposed to be boring, predictable, standardized and reliable and not updated every time a hacker farts. It should be a foundation for other things to be built upon. Breaking it out into gems will result in a messy unpredictable "foundation" where Ruby 193p115 (for example) is not nearly as tightly defined as it should be. In the end the practical result of this will be more gem management headaches, "platform" incompatibilities, and fresh kind of "DLL hell" experienced by Window dev's in the '90's. I'm highly unconvinced that this is a net benefit for Ruby technology.