Specifically: the "library" libraries in the Ruby stdlib (ie, not "String", which is built-in, but things like "net/http") are going to be installed as "default gems". From the wiki, it does not look like you'll be pulling down new gems the first time you run Ruby; rather, the libraries will be structured as gems and registered as gems.
Implication: Ruby will be almost fully dependent on Rubygems; there will be even fewer cases where it's reasonable to run a ruby interp without pulling in Rubygems.
This is probably a win. For instance, it may mitigate the annoying situation where you install Ruby from source but forget to pass the right OpenSSL arguments to "configure" and only find that out a week later, when it's a huge pain to fix the installation.
It's absolutely a win. now the development of the non-core parts of "core" can occur much faster with less dependency upon a much larger project's release schedule and other constraints.
I'm not a hardcore rubyist, but from my experience, this seems like an obvious no-brainer. Gems play an enviable position in the Ruby ecosystem and if often emulated in other programming languages. I can't imagine Ruby (or Rails) being as popular as it is without the help of Gems. Making stdlib a gem means that stdlib can be updated independent of the Ruby language. That means bug fixes, security updates and improvements can be made more often.
There is a similar push in the .NET community to extract certain parts of .NET into NuGet. As it works now, you have to wait for an update for all of .NET (or worse, Visual Studio), which may take years. So called "out of band" releases always seems to have poor support because so many .NET frameworks rely on an upgrade of VS to really use! (E.g., ASP.NET MVC 3) For something fast-moving like the web, this is an eternity.
This reminds me of Armin Ronacher's famous post, "STD stands for Sleazy, Tattered, and Dead" [1]. Basically, the point is that trying to collect too much stuff in the stdlib in the name of "batteries included" results in the packages atrophying and not being updated fast enough (or ever, due to backwards compatibility concerns).
Though I know that the distro maintainers are just going to love this.
There's little reason for this to be the case anymore, given such things as Bundler [0] and RVM [1]. The former lets you define, per project, the exact version of the gem to use. As Rubygems.org hosts all old version in perpetuity, you should never be forced to use a newer version than you have tested.
RVM, meanwhile, has the concept of gemsets, which are completely independent sets of gems which can also be used per-project, which solves the problem of two programs needing different gem versions.
This is interesting since it's the same reasoning behind the addition of an elisp package manager in Emacs 24; they are talking about improving the release cycle by spinning off formerly built-in things like org and gnus into packages that can have their own scheduling.
Please provide a gem list that isn't in the ruby marshal format and in something that is actually usable outside of ruby. JSON, YAML I don't care just not a language specific unused (outside of ruby) serialization format.
That's because Debian deliberately broke gems. I hardly think the Ruby team should compromise anything to better suit Debian. Debian Rubyists just do a little dance on every install to bring up a fresh Rubygems instance.
In theory, it should be reasonable for a stable linux distro release to lock in stable gem versions that have been tested at the same level as the distro.
It's just the case that for Ruby the library ecosystem is being developed at a fast enough pace that few want to settle for gem versions that are 6-18 months old.
If the debian ecosystem was actually functioning as designed, someone would create a trusted apt repo with well tested updates that would perhaps be 3 months behind bleeding edge. This would likely be adequate for most ruby projects. It's my impression that the python community is better supported in the debian world.
Suggestion: the gem utility should be able to generate deb and rpm packages with proper version numbers, and the utility should also have a setting to "pull from distro repository" to allow things like bundler to be compatible with apt... this would allow/entail letting multiple gem versions live side by side, which would likely seem like a distro-smell to many sysadmins (though it isn't one).
How did they break it? If you don't install ruby from apt, you won't get the debian version of ruby or rubygems, and nothing is broken.
Is it reasonable to expect the apt version of ruby + rubygems to play nicely with an arbitrary compiled version that is installed in PATH? It would be nice, but few packages work this way.
It's reasonable to expect that apt's Ruby/Rubygems works with Bundler in the same sense as it's reasonable to expect that apt's Apache will set the right MIME type for a ".html" file, and not set it "application/binary" by default because some configuration file some Debian person thinks should exist isn't there.
Put more simply: if they can't package a rubygems that actually works with the rubygems ecosystem, they should not package rubygems at all.
After their changes, the tool does not function as it was originally intended. Certain sections of the official rubygems documentation give instructions that do not work with the Debian version of rubygems. How is that not broken? In what way did they not break it?
I understand and admire Debian's commitment to cleanly built, working software. Within that context I also understand that rubygems is a big, scary unknown. That said, if the only way to solve the problem is to hack up rubygems until it no longer works as intended, the only real answer is to not ship rubygems within Debian. It just flat out has to be left in "here be dragons" land. As things are right now people just get pissed off that Ruby isn't working correctly under Debian, then they have to go play with dragons anyways.
Does anyone actually use the Debian-packaged gem's for anything at all?
About the first thing I do on any new Debian box is to make sure I run a non-Debian rubygems as the Debian one is hopelessly broken, and install any gems I need via bundler.
The $PATH problem has actually been fixed in Debian unstable; they caved on FHS-compliance and let Rubygems place things in the right bin/ dir. Not sure if other issues persist, but finally some progress has been made.
Yes. People that don't know better, and people that are only installing dist packaged stuff. I know a lot of people in the second group, though most of those doesn't use Ruby.
The amount of control the Debian team wants to retain and the speed at which the Ruby/RubyGems community moves are incompatible. Trying to use Ruby from apt is some kind of sick, masochistic joke.
Implication: Ruby will be almost fully dependent on Rubygems; there will be even fewer cases where it's reasonable to run a ruby interp without pulling in Rubygems.
This is probably a win. For instance, it may mitigate the annoying situation where you install Ruby from source but forget to pass the right OpenSSL arguments to "configure" and only find that out a week later, when it's a huge pain to fix the installation.