Vagrant 1.1+ 不再支援以 RubyGems 作為安裝方式。您必須改用 預先打包好的套件或安裝程式來安裝 Vagrant 1.1+。對於習慣以 gem 安裝的使用者來說，這項改變引發了困惑與不滿交雜的反應。在本文中，我將列舉捨棄 RubyGems 的原因，以及為何從長遠來看這對 Vagrant 社群更好。

我在三年多前最初以 RubyGem 的形式發布了 Vagrant。Vagrant 是以 Ruby 撰寫的，當時我已經很熟悉製作 RubyGems，因此認為這是一種自然的發布機制。

我對當時的這個決定一點也不後悔。Ruby 社群對於前瞻技術非常開放，我認為以 RubyGem 的形式發布確實提升了專案初期的採用率。

然而，自那之後，我逐漸成長並了解到，基於許多原因，RubyGems 已不再是最佳選擇。

在本文中，我將說明為何安裝程式能讓 Vagrant 使用者的體驗更好。在未來的文章中，我會再說明安裝程式對外掛開發者及其生態系的影響。

非 Ruby 使用者

自 Vagrant 於 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 中，我將原本使用的緩慢、純 Ruby 的 tar 函式庫替換為 libarchive，這是一個以 C 撰寫的高效能、穩定且彈性的應用程式與函式庫。libarchive 現在已隨每個 Vagrant 安裝程式一併提供，因此使用者無需再額外安裝另一項相依套件，也無需在意 Vagrant 正在使用它。

在 Vagrant 1.2 中，我將下載器從純 Ruby 的 HTTP 替換為 cURL。這要快得多，並支援更多網路協定，例如 FTP。每個安裝程式都會預先安裝 cURL。同樣地，使用者無需在意。

未來，我將會把純 Ruby 的 SSH 函式庫替換為以 C 撰寫、更穩定且維護更完善的 SSH 函式庫。同樣地，使用者無需在意，但他們會注意到 SSH 變得更加穩定。

透過所有這些變更，我得以在不被使用者察覺的情況下進行重大的相依套件更動。事實上，使用者唯一會注意到的，就是 Vagrant 的體驗變得好多了。速度變快了、不再當機，而且 Vagrant 支援更多功能。

整體而言，Vagrant 變得好很多，正是因為我能夠做出那些透過 RubyGems 發布時無法安全進行的變更。