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