Vagrant 1.1 及以上版本不再支持通过 RubyGems 作为安装方式。取而代之，你必须使用预制软件包或安装程序来安装 Vagrant 1.1 及以上版本。对于习惯了基于 gem 安装的用户来说，这一变动引发了困惑与不满。在本文中，我将逐一说明放弃 RubyGems 的原因，以及为什么从长远来看这对 Vagrant 社区更有好处。

三年多前，我最初以 RubyGem 的形式发布了 Vagrant。Vagrant 本身是用 Ruby 编写的，当时我对制作 RubyGem 已经十分熟练，因此觉得这是一种自然的分发方式。

我丝毫不后悔当初的这个决定。Ruby 社区对前沿技术非常开放，我认为以 RubyGem 的形式分发有助于项目在早期获得更多关注。

不过，此后我逐渐认识到，出于诸多原因，RubyGems 已不再是最佳选择。

在本文中，我将解释为什么安装程序能让 Vagrant 用户的体验变得更好。在今后的文章中，我会再谈安装程序对插件开发者及整个插件生态的影响。

非 Ruby 用户

自 2010 年首次发布以来，Vagrant 已被数百家公司、数千人使用。虽然我没有确切的数据来佐证，但就我接触到的 Vagrant 用户而言，其中大多数都不是 Ruby 开发者。

在推出安装程序之前，我收到的关于 Vagrant 最多的抱怨都与 RubyGems 有关。作为一名 Ruby 开发者，我一直觉得 RubyGems 很简单。但对于 Ruby 社区之外的人来说，我才意识到，要去学习 RubyGems、安装 Ruby 等等，这些负担已经构成了相当高的入门门槛，以至于很多人甚至根本不会去尝试安装 Vagrant。

而另一方面，将 Vagrant 的所有依赖（包括 Ruby 本身）都打包在一起的安装包，则让 Vagrant 的安装变得极其简单。

Bug

Vagrant 有很多外部依赖：Ruby、RubyGems、OpenSSL、zlib、JSON 等等。采用 RubyGems 的方式时，用户必须自行手动安装这些依赖，无论是从源码安装，还是通过自己选择的包管理器安装。

正是由于这种灵活性，我无法在所有可能的环境中测试 Vagrant。我知道 Vagrant 在我的系统上配合我已安装的依赖版本可以正常工作，但无法保证它能在所有系统上都正常运行。

因此，经常会收到这样的 Bug 反馈：Vagrant 所依赖的版本过旧、本身存在缺陷，或是由于权限错误等问题而根本无法正常工作。

我并不在意这被看作是我的问题还是用户的问题。我不会责怪用户没有安装正确的版本，尤其是当他们只是安装了自己软件源中提供的版本时。

然而，当 Vagrant 因环境损坏而崩溃，人们便会将其视为 Vagrant 本身不稳定，这就成了一个大问题——而十有八九，真正的原因其实是环境配置不当。

有了安装程序，我就可以将 Vagrant 所需的所有依赖一并打包交付，并向用户保证 Vagrant 与这些依赖能够正常协作。这一点在 Windows 环境下尤为有用。

灵活性

由于我能够严格控制运行环境，我也得以改进和精细调整 Vagrant 所依赖的组件。

在 Vagrant 1.1 中，我将之前使用的缓慢的纯 Ruby tar 库替换成了 libarchive，一个用 C 编写的高性能、稳定且灵活的程序和库。现在每个 Vagrant 安装程序都会自带 libarchive，因此用户无需再额外安装这一依赖，甚至无需关心 Vagrant 正在使用它。

在 Vagrant 1.2 中，我将下载器由纯 Ruby 的 HTTP 实现换成了 cURL。这要快得多，并且支持更多网络协议，例如 FTP。每个安装程序都会预先内置 cURL。同样，用户也无需关心这些细节。

未来，我还会将纯 Ruby 的 SSH 库替换为一个用 C 编写的、更稳定、维护更完善的 SSH 库。同样，用户无需关心，但会明显感受到 SSH 变得更加稳定。

通过这些改动，我可以在用户毫无察觉的情况下对依赖进行重大调整。实际上，用户唯一能感受到的，就是 Vagrant 的体验变得好多了——速度更快了，不再崩溃了，还支持了更多功能。

总体而言，正因为我能够做出那些通过 RubyGems 分发时无法安全实现的改动，Vagrant 才得以变得好得多。