
The Ruby Standard Library To Be Converted to Gems for Ruby 2.0? - joshuacc
http://www.rubyinside.com/the-ruby-standard-library-to-be-converted-to-gems-for-ruby-2-0-5586.html
======
tptacek
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.

~~~
grandalf
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.

------
jinushaun
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.

------
LeafStorm
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.

[1]: [http://lucumr.pocoo.org/2009/3/2/std-stands-for-sleazy-
tatte...](http://lucumr.pocoo.org/2009/3/2/std-stands-for-sleazy-tattered-and-
dead/)

------
rquantz
Gem compatibility already causes a lot of headaches. Am I wrong to think that
this would add to that?

~~~
necubi
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.

[0] <http://gembundler.com/> [1] <http://beginrescueend.com/gemsets/basics/>

------
JonnieCache
If they're doing this then they should merge bundler into rubygems.

------
technomancy
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.

~~~
grandalf
The changes happening with emacs24 are fantastic... I predict an emacs
renaissance.

------
nwmcsween
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.

------
bretthardin
Anything that helps release cycles for open source to be faster I am all for.
Faster release cycles means faster patches to bugs. woot!

------
cultureulterior
Gem to debian package compability is already terrible. This will make it
worse.

~~~
vidarh
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.

That takes care of that problem.

~~~
technomancy
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.

