Vagrant 1.1 以上版本不再支援以 RubyGems 作為安裝方式。取而代之，你必須使用預先打包好的套件或安裝程式來安裝 Vagrant 1.1 以上的版本。對於習慣透過 gem 安裝的人來說，這造成了困惑與不滿交雜的反應。在這篇文章中，我將一一列舉捨棄 RubyGems 的原因，以及為什麼長遠來看這對 Vagrant 社群更好。

三年多前，我最初是以 RubyGem 的形式發布 Vagrant。Vagrant 是用 Ruby 寫成的，當時我已經很熟悉如何製作 RubyGem，因此覺得這是很自然的發布方式。

我一點也不後悔當初這個決定。Ruby 社群對於前沿技術一向抱持開放態度，我認為以 RubyGem 的形式發布，確實幫助專案在初期獲得了更多關注。

不過，隨著時間過去，我逐漸體會到，基於許多原因，RubyGems 已不再是最佳選擇。

在這篇文章中，我要說明為什麼改用安裝程式能讓 Vagrant 使用者的體驗更好。在之後的文章裡，我會再說明安裝程式對外掛開發者及其生態系的影響。

非 Ruby 使用者

自從 2010 年首次發布 Vagrant 以來，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 語言撰寫、高效能、穩定且彈性的應用程式及函式庫。現在每個 Vagrant 安裝程式都內建了 libarchive，因此使用者不需要再另外安裝這個相依套件，甚至不需要關心 Vagrant 正在使用它。

在 Vagrant 1.2 中，我將下載器從純 Ruby 的 HTTP 實作換成了 cURL。這要快得多，而且支援更多網路協定，例如 FTP。每個安裝程式都會預先內建 cURL。同樣地，使用者完全不需要操心。

未來，我還會將純 Ruby 的 SSH 函式庫替換為以 C 語言撰寫、更穩定且維護更完善的 SSH 函式庫。一樣，使用者不需要操心，但他們會明顯感覺到 SSH 變得更穩定了。

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

整體而言，Vagrant 之所以能變得好得多，正是因為我得以做出那些透過 RubyGems 發布時無法安心進行的改變。