避免 Rack 的冗余 Bundler 依赖声明答案

【问题标题】：Avoiding redundant Bundler dependency declarations for Rack避免 Rack 的冗余 Bundler 依赖声明
【发布时间】：2011-10-20 11:23:15
【问题描述】：

想象一个 Rack 应用程序，它在启动时会创建一些其他 Ruby 应用程序的实例并将路由映射到这些应用程序。此应用程序的 Rack 依赖项为 1.2.2。

现在假设我们正在开发一个将由该应用程序运行的子应用程序。它具有 1.2.6 的 Sinatra 依赖项并使用 Bundler。它的 gemfile 是一片荒芜：

source "http://rubygems.org"

gem "sinatra", "1.2.6"

不幸的是，当我们bundle install这个子应用程序时，Bundler 在不知道父应用程序的 Rack 1.2.2 依赖项的情况下，将安装与 Sinatra 1.2.6 兼容的最新版本的 Rack：目前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)

处理这种情况的正确方法是什么？是的，我们可以明确要求机架 1.2.2，但我们实际上是在声明依赖项的依赖项。我想，理想情况下，父应用程序将是我们的子应用程序需要的宝石，但在这种情况下，我们没有能力做到这一点。

【问题讨论】：

如何准确启动子应用程序？ bundle exec rackup 可能是坚持锁定依赖项的好主意
我猜“最好”的方法是更新您的父应用程序，这样它就不需要“旧”版本的 Rack。

标签： sinatra bundler rack

【解决方案1】：

您的“主”进程应该使用bundle exec 来启动子进程，正如错误消息所建议的那样。

这将强制新应用在其自己的 Gemfile 的捆绑上下文中启动，而不是在全局 gem 上下文中启动。因此，新应用将使用 Rack 1.3.2 或更高版本启动，不是 Rack 1.2.2。

【讨论】：

【解决方案2】：

尝试从 gem local 中删除 Rack 1.2.2

【讨论】：