Bundler - 捆綁包永遠爲特定的寶石

Question

我在哪裏工作，我們開發了幾個Ruby Gems供內部使用。他們都依賴於我們自己的內部寶石以及來自RubyGems.org的第三方寶石的各種組合。

當我們使用構建服務器（ElectricCommander）進行更改時，我們會自動構建寶石，該服務器將它們打包爲寶石並將它們存儲在內部存儲庫中。作爲該過程的一部分，我們運行bundle package --all。直到上週爲止，這一直是我們所有寶石的完美工作。

上週，我們的一個寶石開始花費1個多小時來運行捆綁軟件包命令。它運行成功，但完成需要一個多小時，這有點荒謬。

在我們其他的gem版本上，bundle package命令運行良好，分鐘左右。每個寶石所包含的依賴關係的數量沒有太大差異。他們都建立在相同的環境。

我們正在拉我們的頭髮在這一個。谷歌搜索沒有透露任何人有同樣的問題。有沒有人遇到過這個問題，或者有人知道可能是什麼原因造成的？

Answer 1

我之前有過類似的問題，當時問題中的寶石依賴於另一個有很多版本並且有許多其他依賴關係的gem。在我們的寶石中，我們有另一個gem（它是rails）作爲依賴，而不依賴於特定的版本。

因此，我們必須：

s.add_runtime_dependency "rails" 

當我們增加了一個版本中，我們看到捆紮速度顯著上升：

s.add_runtime_dependency "rails", "~>3.2" 

隨着絕對剛性的版本，它甚至更快：

s.add_runtime_dependency "rails", "3.2.14" 

我認爲，緩慢的原因是它會查看所有的所有依賴關係與您的gemspec中的依賴相匹配的gem版本。正如你可以想象一個已經存在一段時間的gem，並且它本身有很多其他的依賴關係，這可能會成爲相當多的四處尋找。

Answer 2

Bundler非常努力地尋找一組符合您所有捆綁要求的寶石，但在某些情況下，此搜索可能需要很長時間。根據您的Gemfile中的寶石順序，您提供的約束以及在其他寶石中遇到的依賴關係，Bundler可能需要回溯解析過程並重新解析某些寶石。在最壞的情況下，這可能需要指數時間。

Pat Shaughnessy在How does Bundler bundle?中解釋了這個過程。正如他所提到的，在環境中運行Bundler DEBUG_RESOLVER=1可以幫助向您展示發生了什麼。

您可以通過更改Gemfile中的寶石順序或使用Shadwell建議的更具體的版本約束來解決這些問題。