Vagrant 1.1+ 不再支持将 RubyGems 作为安装方式。相反，你必须使用预制软件包或安装程序来安装 Vagrant 1.1+。对于习惯了基于 gem 的安装方式的人来说，这引发了困惑和不满。在这篇文章中，我将列出放弃 RubyGems 的原因，以及为什么从长远来看，这对 Vagrant 社区更有利。

三年多以前，我最初以 RubyGem 的形式发布了 Vagrant。Vagrant 使用 Ruby 编写，而当时我已经很熟悉如何制作 RubyGems，因此我认为这是一种很自然的分发方式。

我从未后悔过这个决定。Ruby 社区非常乐于接受前沿技术，而我认为，以 RubyGem 的形式进行分发促进了项目最初的推广。

然而从那以后，我不断成长和学习，也逐渐认识到，RubyGems 已经不再是最佳选择，原因有很多。

在这篇文章中，我将解释为什么安装程序能让 Vagrant 用户的使用体验更好。在未来的一篇文章中，我会解释安装程序将如何影响插件开发者及其生态系统。

非 Ruby 用户

自 2010 年 Vagrant 首次发布以来，它已经发展到被数百家公司和数千人使用。虽然我没有确切的数据来支持这一点，但我接触到的大多数 Vagrant 用户都不是 Ruby 开发者。

在制作安装程序之前，我收到的关于 Vagrant 的首要抱怨就是 RubyGems。作为 Ruby 用户，我一直认为 RubyGems 很简单。但对于 Ruby 社区之外的任何人来说，我了解到，他们必须学习 RubyGems、安装 Ruby，等等；这种负担已经构成了足够高的入门门槛，以至于许多人甚至没有尝试安装 Vagrant。

另一方面，将 Vagrant 的所有依赖项（包括 Ruby）打包在一起的软件包，能让 Vagrant 的安装变得极其简单。

缺陷

Vagrant 有许多外部依赖项：Ruby、RubyGems、OpenSSL、zlib、JSON 等。采用 RubyGems 的方式时，用户需要自行安装这些依赖项，可以从源代码安装，也可以使用自己选择的软件包管理器。

有了这种灵活性，我无法在所有可能的环境中测试 Vagrant。我知道 Vagrant 在我的系统上、配合我所安装的依赖项版本能够正常工作，但不知道它是否能在每个系统上运行。

因此，我们经常会收到这样的缺陷报告：Vagrant 使用了过旧的依赖项，这些依赖项本身存在缺陷，或者仅仅因为权限错误等问题而无法正常工作。

我不在乎这被认为是我的错还是用户的错。我不会责怪用户没有安装正确的版本，尤其是当他们只是安装了软件包仓库中提供的版本时。

然而，当 Vagrant 因环境损坏而崩溃，随后人们把这看作 Vagrant 本身不稳定时，这就是一个非常严重的问题；而十次中有九次，问题其实都源于环境配置不当。

使用安装程序后，我可以将 Vagrant 所需的全部依赖项随程序一同发布，并向用户保证 Vagrant 会配合这些依赖项正常工作。这在 Windows 环境中尤其有帮助。

灵活性

由于我能够严格控制环境，因此可以改进并微调 Vagrant 所依赖的组件。

在 Vagrant 1.1 中，我用 libarchive 替换了之前使用的老旧、缓慢的纯 Ruby tar 库。libarchive 是一个使用 C 编写的高性能、稳定且灵活的应用程序和库。现在，每个 Vagrant 安装程序都会附带 libarchive，因此用户不必再安装另一个依赖项，也不必真正关心 Vagrant 正在使用它。

在 Vagrant 1.2 中，我将下载器从使用纯 Ruby HTTP 改为使用 cURL。这样速度快得多，并且支持更多网络协议，例如 FTP。每个安装程序都会预先内置 cURL。同样，用户无需关心这些细节。

未来，我会用一个更加稳定、维护良好且使用 C 编写的 SSH 库，替换纯 Ruby SSH 库。用户仍然不必关心这些变化，但会注意到 SSH 变得更加稳定。

有了所有这些变化，我就可以在不让用户察觉的情况下，对依赖项进行重大调整。事实上，用户唯一能注意到的，就是 Vagrant 的使用体验大幅改善了：运行速度更快了，不再崩溃了，并且 Vagrant 支持更多功能。

总的来说，Vagrant 之所以有了很大改进，是因为通过 RubyGems 分发时我无法安全地进行这些变更，而现在我可以了。