Docs header transparent bg

bundle update

bundle-update - 将您的 gems 更新到最新可用版本

bundle update *gems [--all]
                        [--group=NAME]
                        [--source=NAME]
                        [--local]
                        [--ruby]
                        [--bundler[=VERSION]]
                        [--full-index]
                        [--jobs=JOBS]
                        [--quiet]
                        [--patch|--minor|--major]
                        [--redownload]
                        [--strict]
                        [--conservative]

描述

更新指定的 gems(如果使用 --all 标志,则更新所有 gems),忽略之前在 Gemfile.lock 中指定的已安装 gems。通常,您应该使用 bundle install(1) 在不同机器上安装完全相同的 gems 和版本。

您可以使用 bundle update 显式更新 gem 的版本。

选项

--all
更新 Gemfile 中指定的所有 gems。
--group=<name>, -g=[<name>]
仅更新指定组中的 gems。例如,您可以使用 bundle update --group development 更新开发组中的所有 gems。您还可以调用 bundle update rails --group test 来更新 rails gem 和测试组中的所有 gems,例如。
--source=<name>
Gemfile(5) 中使用的 :git:path 源的名称。例如,对于 :githttp://github.com/rails/rails.git,您将调用 bundle update --source rails
--local
不要尝试远程获取 gems,而是使用 gem 缓存。
--ruby
将锁定版本的 Ruby 更新到当前版本的 Ruby。
--bundler
将锁定版本的 bundler 更新到调用的 bundler 版本。
--full-index
回退到使用所有 gems 的单文件索引。
--jobs=[<number>], -j[<number>]
指定要并行运行的作业数。默认值为可用处理器的数量。
--retry=[<number>]
对失败的网络或 git 请求重试 number 次。
--quiet
仅输出警告和错误。
--redownload
强制下载每个 gem。
--patch
优先更新到下一个补丁版本。
--minor
优先更新到下一个次要版本。
--major
优先更新到下一个主要版本(默认)。
--strict
不允许任何 gem 更新到超过最新的 --patch | --minor | --major
--conservative
使用 bundle install 的保守更新行为,不允许更新间接依赖项。

更新所有 Gems

如果您运行 bundle update --all,bundler 将忽略所有先前安装的 gems,并根据所有源中所有 gems 的最新版本再次解析所有依赖项。

考虑以下 Gemfile(5)

source "https://rubygems.org.cn"

gem "rails", "3.0.0.rc"
gem "nokogiri"

当您第一次运行 bundle install(1) 时,bundler 将解析所有依赖项,一直到最底层,并安装您需要的。

Fetching gem metadata from https://rubygems.org.cn/.........
Resolving dependencies...
Installing builder 2.1.2
Installing abstract 1.0.0
Installing rack 1.2.8
Using bundler 1.7.6
Installing rake 10.4.0
Installing polyglot 0.3.5
Installing mime-types 1.25.1
Installing i18n 0.4.2
Installing mini_portile 0.6.1
Installing tzinfo 0.3.42
Installing rack-mount 0.6.14
Installing rack-test 0.5.7
Installing treetop 1.4.15
Installing thor 0.14.6
Installing activesupport 3.0.0.rc
Installing erubis 2.6.6
Installing activemodel 3.0.0.rc
Installing arel 0.4.0
Installing mail 2.2.20
Installing activeresource 3.0.0.rc
Installing actionpack 3.0.0.rc
Installing activerecord 3.0.0.rc
Installing actionmailer 3.0.0.rc
Installing railties 3.0.0.rc
Installing rails 3.0.0.rc
Installing nokogiri 1.6.5

Bundle complete! 2 Gemfile dependencies, 26 gems total.
Use `bundle show [gemname]` to see where a bundled gem is installed.

如您所见,即使您在 Gemfile(5) 中有两个 gems,您的应用程序也需要 26 个不同的 gems 才能运行。Bundler 会记住它在 Gemfile.lock 中安装的精确版本。下次您运行 bundle install(1) 时,bundler 会跳过依赖项解析,并安装与上次安装相同的 gems。

在将 Gemfile.lock 检查到版本控制中并在另一台机器上克隆它之后,运行 bundle install(1) 仍然会安装您上次安装的 gems。您无需担心 erubismail 的新版本会更改您使用的 gems。

但是,有时您可能希望将使用的 gems 更新到仍然与 Gemfile(5) 中的 gems 匹配的最新版本。

为此,请运行 bundle update --all,它将忽略 Gemfile.lock,并再次解析所有依赖项。请记住,此过程可能会导致 25 个 gems 的集合发生显著变化,这取决于 gem 作者自上次运行 bundle update --all 以来发布的新 gems 的要求。

更新 Gems 列表

有时,您想更新 Gemfile(5) 中的单个 gem,并将您指定的其他 gems 锁定到 Gemfile.lock 中的版本。

例如,在上面的场景中,假设 nokogiri 发布了版本 1.4.4,您想更新它,但更新 Rails 及其所有依赖项。为此,请运行 bundle update nokogiri

Bundler 将更新 nokogiri 及其任何依赖项,但会保留 Rails 及其依赖项。

重叠依赖项

有时,在 Gemfile(5) 中声明的多个 gems 由同一个二级依赖项满足。例如,考虑 thinrack-perftools-profiler 的情况。

source "https://rubygems.org.cn"

gem "thin"
gem "rack-perftools-profiler"

thin gem 依赖于 rack >= 1.0,而 rack-perftools-profiler 依赖于 rack ~> 1.0。如果您运行 bundle install,您将得到

Fetching source index for https://rubygems.org.cn/
Installing daemons (1.1.0)
Installing eventmachine (0.12.10) with native extensions
Installing open4 (1.0.1)
Installing perftools.rb (0.4.7) with native extensions
Installing rack (1.2.1)
Installing rack-perftools_profiler (0.0.2)
Installing thin (1.2.7) with native extensions
Using bundler (1.0.0.rc.3)

在这种情况下,这两个 gems 都有自己的依赖项集,但它们共享 rack。如果您运行 bundle update thin,bundler 将更新 daemonseventmachinerack,它们是 thin 的依赖项,但不是 open4perftools.rb,它们是 rack-perftools_profiler 的依赖项。请注意,bundle update thin 将更新 rack,即使它也是 rack-perftools_profiler 的依赖项。

简而言之,默认情况下,当您使用 `bundle update` 更新 gem 时,bundler 会更新该 gem 的所有依赖项,包括那些也是其他 gem 的依赖项的依赖项。

为了防止更新间接依赖项,在 1.14 版本之前,唯一的选择是在 bundle install(1) 中使用 `CONSERVATIVE UPDATING` 行为。

在这种情况下,在 Gemfile(5) 中手动更新 `thin` 版本,然后运行 bundle install(1) 将只更新 `daemons` 和 `eventmachine`,而不会更新 `rack`。有关更多信息,请参阅 bundle install(1) 中的 `CONSERVATIVE UPDATING` 部分。

从 1.14 版本开始,指定 `--conservative` 选项也将阻止更新间接依赖项。

补丁级别选项

1.14 版本引入了 4 个补丁级别选项,这些选项将影响 gem 版本的解析方式。可以使用以下选项之一:`--patch`、`--minor` 或 `--major`。`--strict` 可以进一步影响解析。

--patch
优先更新到下一个补丁版本。
--minor
优先更新到下一个次要版本。
--major
优先更新到下一个主要版本(默认)。
--strict
不允许任何 gem 更新到超过最新的 --patch | --minor | --major

当 Bundler 解析要使用哪些版本来满足 Gemfile 或父 gem 中声明的要求时,它会查找所有可用版本,过滤掉不满足要求的任何版本,然后默认情况下,从最新到最旧排序它们,并按此顺序考虑它们。

提供一个补丁级别选项(例如 `--patch`)会更改满足版本排序顺序,导致 Bundler 在考虑其他版本之前考虑最新的 `--patch` 或 `--minor` 版本。请注意,如果需要找到合适的依赖关系图,仍然可以解析超出指定补丁级别的版本。

例如,如果 gem 'foo' 锁定在 1.0.2 版本,并且 Gemfile 中没有定义 gem 要求,并且存在 1.0.3、1.0.4、1.1.0、1.1.1、2.0.0 版本,则默认情况下(`--major`)的优先级顺序将是“2.0.0、1.1.1、1.1.0、1.0.4、1.0.3、1.0.2”。

如果使用 `--patch` 选项,优先级顺序将更改为“1.0.4、1.0.3、1.0.2、1.1.1、1.1.0、2.0.0”。

如果使用 `--minor` 选项,优先级顺序将更改为“1.1.1、1.1.0、1.0.4、1.0.3、1.0.2、2.0.0”。

将 `--strict` 选项与任何补丁级别选项结合使用将删除超出补丁级别选项范围的任何版本,以确保没有 gem 被更新到那么远。

继续之前的示例,如果同时使用--patch--strict选项,可用于解析的版本将是“1.0.4、1.0.3、1.0.2”。如果使用--minor--strict,则将是“1.1.1、1.1.0、1.0.4、1.0.3、1.0.2”。

Gemfile 中定义的 Gem 需求仍然是决定可用版本的首要因素。如果 Gemfile 中对foo的 Gem 需求是'~> 1.0',这将与提供--minor--strict选项的效果相同。

补丁级别示例

假设有以下 Gem 规范

foo 1.4.3, requires: ~> bar 2.0
foo 1.4.4, requires: ~> bar 2.0
foo 1.4.5, requires: ~> bar 2.1
foo 1.5.0, requires: ~> bar 2.1
foo 1.5.1, requires: ~> bar 3.0
bar with versions 2.0.3, 2.0.4, 2.1.0, 2.1.1, 3.0.0

Gemfile

gem 'foo'

Gemfile.lock

foo (1.4.3)
  bar (~> 2.0)
bar (2.0.3)

案例

#  Command Line                     Result
------------------------------------------------------------
1  bundle update --patch            'foo 1.4.5', 'bar 2.1.1'
2  bundle update --patch foo        'foo 1.4.5', 'bar 2.1.1'
3  bundle update --minor            'foo 1.5.1', 'bar 3.0.0'
4  bundle update --minor --strict   'foo 1.5.0', 'bar 2.1.1'
5  bundle update --patch --strict   'foo 1.4.4', 'bar 2.0.4'

在案例 1 中,bar 被升级到 2.1.1,这是一个次要版本升级,因为 foo 1.4.5 的依赖关系要求这样做。

在案例 2 中,只请求解锁 foo,但 bar 也允许移动,因为它不是 Gemfile 中声明的依赖关系。

在案例 3 中,bar 上升了一个完整的 major 版本,因为现在 foo 优先进行 minor 版本升级,当它升级到 1.5.1 时,它需要 bar 的 3.0.0 版本。

在案例 4 中,foo 优先升级到 minor 版本,但 1.5.1 无法工作,因为 --strict 标志从考虑范围中排除了 bar 3.0.0,因为它是一个 major 版本升级。

在案例 5 中,由于 --strict 标志,foo 和 bar 的所有 minor 或 major 版本升级都被排除在考虑范围之外,因此它们最多只能升级到 1.4.4 和 2.0.4。

通常,在使用 bundler 管理应用程序时,您应该使用以下工作流程

  • 首次创建 Gemfile(5) 后,运行

    $ bundle install

  • 将生成的 Gemfile.lock 检查到版本控制中

    $ git add Gemfile.lock

  • 在另一台开发机器上检出此仓库时,运行

    $ bundle install

  • 在部署机器上检出此仓库时,运行

    $ bundle install --deployment

  • 更改 Gemfile(5) 以反映新的或更新的依赖关系后,运行

    $ bundle install

  • 确保将更新的 Gemfile.lock 检查到版本控制中

    $ git add Gemfile.lock

  • 如果 bundle install(1) 报告冲突,请手动更新 Gemfile(5) 中更改的特定 Gem

    $ bundle update rails thin

  • 如果要将所有 Gem 更新到与 Gemfile(5) 中列出的 Gem 匹配的最新可能版本,请运行

    $ bundle update --all

在 GitHub 上编辑此文档,如果您发现错误或遗漏内容。