为什么我们要将 Ruby 1.9.2/1.9.3 gems 安装到 1.9.1 文件夹中？答案

【问题标题】：Why are we installing Ruby 1.9.2/1.9.3 gems into a 1.9.1 folder?为什么我们要将 Ruby 1.9.2/1.9.3 gems 安装到 1.9.1 文件夹中？
【发布时间】：2011-12-19 16:20:34
【问题描述】：

这是因为gem 命令使用的Gem 安装目录（在使用gem env 时看到）设置为：

<base_ruby_dir>/lib/ruby/gems/1.9.1

我的问题是为什么？

该文件夹不应该被调用吗：

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

或

<base_ruby_dir>/lib/ruby/gems/1.9

否则不能每个版本的 Ruby 都有一个，例如：

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

我知道这不是一个严重的问题，我只是想知道。

【问题讨论】：

标签： ruby rubygems

【解决方案1】：

在 Ruby 1.9.0 中，C 接口从 Ruby 1.8 系列更改。

必须重新编译编译为本机代码的 Gem。

界面在 Ruby 1.9.1 中再次更改，并在 Ruby 1.9.2 和 3 中保持不变。这解释了您在路径中看到的 1.9.1。

这个想法是，您可以在系统上安装不同版本的 Ruby，并且可以在具有相同 C api 的组内共享 gem。因此 Ruby 1.8.6 和 1.8.7 可以共享它们的 gem，Ruby 1.9.1、.2 和 .3 也可以。

不过，这不一定是最好的主意。无论如何，大多数人使用rvm 来访问不同版本的Ruby，rvm 将每个版本的gem 分开，与C api 版本无关。

【讨论】：

好的，我明白了。所以 1.9.1 意味着 gem 符合 Ruby 1.9.1 中使用的 C 接口？这种暴露实现细节不是吗？从 gem 的最终用户的角度来看，我为什么要关心？我是否会像 1.9.1 和 1.9.4 这样并排看到两个文件夹？如果不是，我又何必在乎呢？
对。 C Api绝对公开了实现细节！ Gem 用户不应该关心路径。最后两个问题的答案已编辑
对我来说，问题完全在于目录命名约定。如果我们知道对 Ruby 的 C API 的更改将导致使用该版本的 Ruby 重新编译所有 gem，那么我有一个名为 1.9.1 的文件夹，其中包含 gem，或一个文件夹称为 1.9.2（或其他）。如果我不能同时拥有两者（对于一个版本的 Ruby），那么 1.9.x 会更明智。我从未见过用于存储多个 Ruby 版本的 gem 的同一个文件夹——这实际上是一个真正的用例吗？

【解决方案2】：

我认为这是因为这些版本应该是兼容的，如果您有单独的目录，则必须使用它重新安装所有 gem。这样您就可以升级 ruby 的版本，而无需重新安装所有 gem。

【讨论】：

嗯，有道理。但在这种情况下，为什么不调用文件夹 1.9 或 1.9.x 呢？我觉得很奇怪。
Ruby Debian 软件包也是如此。我从一个名为 ruby1.9.1 的包中安装了 1.9.2。可执行文件也被这样命名。
无法保证（不幸的是）ABI 在整个 1.9.x 生命周期内保持不变。如果 1.9.4 突然使用了与 1.9.1-1.9.3 不兼容的 ABI，那么你的 1.9.x 路径突然命名错误。
如果他们要发布不兼容的版本（但他们已经表示不会，我认为）他们可能会将文件夹重命名为 1.9.4。
我认为名称清理版本是明智的。