8 ms·

The Ruby Standard Library To Be Converted to Gems for Ruby 2.0?

44 points by joshuacc 15y ago

rquantz 15y ago
Gem compatibility already causes a lot of headaches. Am I wrong to think that this would add to that?
- necubi 15y ago
  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/ http://gembundler.com/ [1] http://beginrescueend.com/gemsets/basics/ http://beginrescueend.com/gemsets/basics/
jinushaun 15y ago
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.
bretthardin 15y ago
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 15y ago
Gem to debian package compability is already terrible. This will make it worse.
- tptacek 15y ago
  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.
  - grandalf 15y ago
    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).
    - tptacek 15y ago
      In my experience the Debian problem goes way beyond not having the most recent gems; they broke Rubygems, so that things like Bundler don't work. No matter what they thought was reasonable, they should have just left gems alone.
      - grandalf 15y ago
        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.
LeafStorm 15y ago
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-tattered-and-dead/ http://lucumr.pocoo.org/2009/3/2/std-stands-for-sleazy-tatte...
tptacek 15y ago
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 15y ago
  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.
JonnieCache 15y ago
If they're doing this then they should merge bundler into rubygems.
technomancy 15y ago
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 15y ago
  The changes happening with emacs24 are fantastic... I predict an emacs renaissance.
nwmcsween 15y ago
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.

44 points by joshuacc 15y ago

rquantz 15y ago

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

necubi 15y ago
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/ http://gembundler.com/ [1] http://beginrescueend.com/gemsets/basics/ http://beginrescueend.com/gemsets/basics/

jinushaun 15y ago

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.

bretthardin 15y ago

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 15y ago

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

tptacek 15y ago
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.
- grandalf 15y ago
  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).
  - tptacek 15y ago
    In my experience the Debian problem goes way beyond not having the most recent gems; they broke Rubygems, so that things like Bundler don't work. No matter what they thought was reasonable, they should have just left gems alone.
    - grandalf 15y ago
      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.

LeafStorm 15y ago

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-tattered-and-dead/ http://lucumr.pocoo.org/2009/3/2/std-stands-for-sleazy-tatte...

tptacek 15y ago

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 15y ago
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.

JonnieCache 15y ago

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

technomancy 15y ago

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 15y ago
The changes happening with emacs24 are fantastic... I predict an emacs renaissance.

nwmcsween 15y ago

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.