避免冗餘的Bundler依賴關係聲明Rack

想象一下Rack應用程序，它在啓動時創建一些其他Ruby應用程序的實例並將路由映射到這些應用程序。該應用程序具有1.2.2的機架依賴性。避免冗餘的Bundler依賴關係聲明Rack

現在想象一下，我們正在開發一個將由此應用程序運行的子應用程序。它具有1.2.6的Sinatra依賴性並使用Bundler。它的Gemfile是一片荒蕪：

source "http://rubygems.org" 

gem "sinatra", "1.2.6"

不幸的是，當我們bundle install這個子應用，捆紮機，無父應用的機架1.2.2依賴的知識，將安裝最新的機架版本是與Sinatra 1.2.6兼容：目前1.3.2。我們Gemfile.lock的將是：

GEM 
    remote: http://rubygems.org/ 
    specs: 
    rack (1.3.2) 
    sinatra (1.2.6) 
     rack (~> 1.1) 
     tilt (< 2.0, >= 1.2.2) 
    tilt (1.3.2) 

PLATFORMS 
    ruby 

DEPENDENCIES 
    sinatra (= 1.2.6)

當我們嘗試啓動父應用程序（這將啓動我們的子應用程序），我們會得到：

You have already activated rack 1.2.2, but your Gemfile requires rack 1.3.2. Consider using bundle exec. (Gem::LoadError)

什麼是正確的方法處理這種情況？是的，我們可以明確地要求rack 1.2.2，但我們實際上會說明依賴關係的依賴性。我想，理想情況下，父應用程序將是我們的子應用程序需要的寶石，但在這種情況下，我們沒有能力實現它。

來源

2011-08-05 Brennan Roberts

你如何準確地開始你的子應用程序？ 'bundle exec rackup'可能是一個不錯的主意，堅持鎖定的依賴關係 –

我猜「最好」的方法是更新您的父應用程序，因此它不需要Rack的「舊」版本。 – henrikhodne

嘗試從寶石當地

來源

2012-03-06 08:42:02 CodeGroover

你的「主」過程中應使用bundle exec啓動子進程刪除機架1.2.2，只是作爲錯誤消息建議。

這將迫使新應用程序在其內部啓動自己的Gemfile的捆綁上下文，而不是全局gem上下文。因此，新應用將使用Rack 1.3.2或更高版本，而不是 Rack 1.2.2啓動。

來源

2013-10-31 01:34:14

避免冗餘的Bundler依賴關係聲明Rack

回答

相關問題