Gem 源之辩：GitHub vs RubyForge

GitHub 最近启用了自己的 RubyGems 服务器，使得发布 gems 变得轻而易举。你只需要在代码库的根目录提供一个 gemspec，并在 GitHub 的配置中选 上一个勾选框，gem 就会构建好并可以供人安装。为了避免和其他用户的 gems 发生冲突，它以用户名为前缀，格式如 _username-project_。

现在 RubyGems 的用户不再是只有 RubyForge 一个 gems 源了，但是对于可选的 GitHub 源还需要进行设置。这似乎不是什么大障碍，但是依然有些问题，正如 Magnus Holm 在 blog 中指出的那样。看起来最大的问题就是自动依赖管理了，因为 RubyGems 的依赖判断都基于同一个服务器，所以就没法正常工作。另外，你还需要知道在 GitHub 上提供某个 gem 的用户的用户名才行。

为了更深入的了解，InfoQ 采访了 RubyGems 的维护者 Eric Hodel、来自 GitHub 的 PJ Hyett 以及来自 RubyForge 的 Tom Copeland。

Eric Hodel 详细地介绍了问题的细节：

最严重的潜在问题莫过于带有破折号（dash）的 gems 了。一个恶意的用户可以去 GitHub 创建一个叫 _net_ 的帐户，并发布一个 _ssh_ 包，版本比 RubyForge 的 _net-ssh_ 还要高。那么 RubyGems 就会安装那个 GitHub 上面的 gem，而这样做是错误的。不幸的是很多时候这被当成一个特性来使用。gems.rubyonrails.org（还有其他开发者）在 gems 中包含开发版，并和 gems.rubyforge.org 的名字相同。大家希望能够匹配以便可以让 RubyGems 安装开发版。

添加源就和随便安装来自互联网的软件一样危险。

目 前解决这个问题的最好办法就是 gem 作者为他们发布的 gems 做签名。这样 gem 用户可以溯及一个 gem 至可信的源。我不确定通过它来建立互联网的信任有 多难，但是我已经在 hoe 中添加了代码，在你运行rake generate\_key（详见ri Hoe) 以后会自动为 gems 做签名。关于签名和验证 gems 的详细文档，请参阅ri Gem::Security。

因 为 gems 在 RubyForge 和 GitHub 都可以发布，那么就需要说到交叉依赖的问题。这样可以允许 gem 作者说“我依赖 brixen-mspec 或 者 rubyspec-mspec 或者 mspec”。John Barnette 和 Yehuda Katz 对实现这个比较感兴趣，但是我还没听说有什么进展。

目前，还得用户自己手动将 gems.github.com 添加到 RubyGems 的源中才能获得 GitHub 的 gems。Eric 说他“并不很反对 [把 GitHub 添加到默认源中]，但是不知道在没有交叉依赖的情况下，这玩意到底有没有用”。

来自 GitHub 的 Pj Hyett 对 Eric 的评论表示赞同：

Eric 担心的关于命名冲突的问题同样也是我们所担心的，一个叫做 _net_ 的用户建立了一个叫做 _ssh_ 的 gem 的场景实际已经发生了。幸运的是，这只是有人向我们展示这个缺陷以引起我们的注意。当然，并不是我们所有的用户都那么友善，所以我们需要找到解决方案。我们可不想让我们的服务把我们每天使用的系统给干掉。最开始，我们本打算在 GitHub 以 _username/repo-name_ 的形式来构建 gems，这样命名冲突就不是个问题了。它还能模拟我们的 URL 结构以带来便利。可不幸的是，斜杠在 RubyGems 中不支持，而我们又不想通过打补丁才能让用户使用 GitHub 的 gems。

来自 RubyForge 的 Tom Copeland 说道关于 RubyForge 的项目自动发布 gems 的想法：

可 能我们需要在项目的 admin 标签中加点儿什么，可以让用户指向自己 svn/git 代码库的 gemspec，然后我们来构建它；或者指向代码库的根目录， 这样我们可以查找 lib 目录，并使用项目名称作为 gem 名，而将 svn 的修订版作为 gem 号。[…] 这个特性目前的需求大吗？

另外一种可能是在 GitHub 上添加一个功能，可以“创建 RubyForge 项目”或者“发布到 RubyForge”。但是 Tom 指出，“目前在 RubyForge 项目的批准有手工的步骤。我们需要梳理如何能自动处理来自 GitHub 的项目创建请求。”

Pj Hyett 如此评价这个主意：

我并不是很反对“发布到 RubyForge”按钮这个主意，但是很坦率的说，我更希望我们的系统和他们站点的工作方式相一致。在 GitHub 构建一个 gem 就像在代码库中提交代码那么简单，我们的用户现在就是这么做的，所以这个主意就别去想它好了。即是说，经常有用户对于构建 gems 有自己的需求，而这些需求基于安全考虑或者其他一些原因我们可能永远都无法满足，所以如果一个用户需要做一些我们暂时提供不了的事情的话，我们还是推荐他们使用 RubyForge。

总结一下，我们看到有些人对解决这个问题有兴趣，但是可能还尚需时日才能搞定它。

在 GitHub 发布 Gems 是自动的，在 RubyForge 发布 Gems 也可以通过 Ryan Davis 的 Hoe 做到自动化，这是个 helper，来协助 Rake、RubyGems 和其他一些东西。它包括一个 task，可以在 RubyForge 上发布 Gems。一旦 Hoe 正确安装，只需要一个简单的 rake release VERSION=x.y.z 就能够发布。关于 Hoe 更多的详情，请参阅在Nuby on Rails 上的Hoe 教程。

你在GitHub 上托管了项目吗？如果是的话，你在RubyForge 也发布了吗？你是怎么使用的（工具、脚本或者任务）？

查看英文原文： Pros and Cons of GitHub vs RubyForge as Gem Source