21

This comes about because the Gem installation directory used by the gem command, seen when using gem env, is set to something like:

<base_ruby_dir>/lib/ruby/gems/1.9.1

My question is why?

Shouldn't the folder be called:

<base_ruby_dir>/lib/ruby/gems/1.9.x

or

<base_ruby_dir>/lib/ruby/gems/1.9

or else couldn't there be one per version of Ruby, like:

c:/ruby191/lib/ruby/gems/1.9.1
c:/ruby192/lib/ruby/gems/1.9.2
c:/ruby193/lib/ruby/gems/1.9.3

Not a critical problem I know, I was just wondering.

Ben
  • 1,321
  • 15
  • 30

2 Answers2

28

In Ruby 1.9.0, the C interface was changed from the Ruby 1.8 series.

Gems that compile to native code had to be recompiled.

The interface was again changed in Ruby 1.9.1 and kept the same in Ruby 1.9.2 & 3. This explains the 1.9.1 you are seeing in your path.

The idea is that you can install different versions of Ruby on your system and that gems would be shared within groups having the same C api. So Ruby 1.8.6 and 1.8.7 could share their gems, and so could Ruby 1.9.1, .2 and .3.

It's not necessarily the best idea, though. In any case, most people use rvm to access different versions of Ruby and rvm keeps gems separate for each version, irrespective of the C api version.

Marc-André Lafortune
  • 78,216
  • 16
  • 166
  • 166
  • Ok, I get that. So 1.9.1 means the gem conforms to the C interface used in Ruby 1.9.1? This kind of exposes implementation details doesn't it? From the point of view of an end-user of a gem why do I care? And am I ever going to see two folders side by side like 1.9.1 and 1.9.4? If not, again, why do I care? – Ben Dec 19 '11 at 23:35
  • Right. The C Api *most definitely* exposes implementation details! Gem users shouldn't care about the path. Answer edited for the last two questions – Marc-André Lafortune Dec 20 '11 at 01:26
  • To me the question is all about the directory naming convention. If we know that a change to Ruby's C API is going to cause a recompile of all gems using that version of Ruby then I've either got a folder called 1.9.1 with gems in, *or* a folder called 1.9.2 (or whatever). If I can't have both (for one version of Ruby) then 1.9.x would be more sensible. I've never seen the same folder used to store the gems for multiple versions of Ruby - is that actually a real use-case? – Ben Dec 20 '11 at 09:18
0

I think it's because these versions should be compatible, and if you had separate directories, you'd have to reinstall all your gems with it. This way you can upgrade the version of ruby without having to reinstall all the gems.

DGM
  • 26,629
  • 7
  • 58
  • 79
  • 1
    Hmm yeah, that makes sense. But in that case why not call the folder 1.9 or 1.9.x? Seems odd to me. – Ben Dec 19 '11 at 16:48
  • Its the same with the Ruby Debian packages. I installed 1.9.2 from a package entitled ruby1.9.1. The executable was named that too. – Linuxios Dec 19 '11 at 16:57
  • There's no guarantee (unfortunately) that the ABI will remain the same for the entire 1.9.x lifecycle. If 1.9.4 suddenly uses an ABI that breaks compatibility with 1.9.1-1.9.3, then your 1.9.x path is suddenly named incorrectly. – jgoldschrafe Sep 11 '12 at 04:26
  • If they were to release an incompatibility (But they have expressed that they won't, I think) they would probably then rename the folder to 1.9.4. – DGM Sep 11 '12 at 14:49
  • I think a name-cleanup release would be sensible. – port5432 Oct 30 '12 at 09:09