bundle-update - 参考手册、选项、命令示例

姓名

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

概要

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

描述

更新指定的 gem（所有 gem，如果使用 --all 标志），忽略 Gemfile.lock 中指定的先前安装的 gem。一般来说，您应该使用bundle install(1)bundle-install.1.html在机器上安装完全相同的gem和版本。

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

选项

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

更新所有宝石

如果您运行bundle update --all，bundle 将忽略任何以前安装的 gem，并根据源中可用的所有 gem 的最新版本再次解析所有依赖项。

考虑以下 Gemfile(5)：

source "https://rubygems.org"

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

当您第一次运行bundle install(1) bundle-install.1.html时，bundler将解析所有依赖项，一直向下，并安装您需要的内容：

Fetching gem metadata from https://rubygems.org/.........
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) 中有两个 gem，您的应用程序也需要 26 个不同的 gem 才能运行。 Bundler 会记住它在 Gemfile.lock 中安装的确切版本。下次运行bundle install(1) bundle-install.1.html时，bundle 会跳过依赖项解析并安装上次安装的相同 gem。

将Gemfile.lock签入版本控制并将其克隆到另一台计算机上后，运行bundle install(1)bundle-install.1.html将仍然安装上次安装的 gem。您无需担心新版本的erubis或mail会改变您使用的宝石。

但是，有时您可能希望将正在使用的 gem 更新为仍与 Gemfile(5) 中的 gem 匹配的最新版本。

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

更新宝石列表

有时，您想要更新 Gemfile(5) 中的单个 gem，并将指定的其余 gem 保留为 Gemfile.lock 中的版本锁定。

例如，在上面的场景中，假设 nokogiri 发布了版本 1.4.4，并且您想要更新它而不更新 Rails 和所有它的依赖项。为此，请运行bundle update nokogiri。

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

重叠的依赖关系

有时，在 Gemfile(5) 中声明的多个 gem 可以通过相同的二级依赖项来满足。例如，考虑thin和rack-perftools-profiler的情况。

source "https://rubygems.org"

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

thin gem 取决于 rack >= 1.0，而 rack-perftools-profiler 取决于 rack ~> 1.0 。如果运行捆绑安装，您将得到：


Fetching source index for https://rubygems.org/
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)

在这种情况下，两个 gem 有自己的一组依赖项，但它们共享共同的rack。如果您运行bundle update Thin，bundle将更新守护进程、eventmachine和rack，它们是依赖项>thin，但不是 open4 或 perftools.rb，它们是 rack-perftools_profiler 的依赖项。请注意，bundle update Thin 将更新 rack，即使它也是 rack-perftools_profiler 的依赖项。

简而言之，默认情况下，当您使用bundle update更新gem时，bundler将更新该gem的所有依赖项，包括那些也是另一个gem的依赖项。

为了防止更新间接依赖项，在版本 1.14 之前，唯一的选择是捆绑安装（1）bundle-install.1.html中的保守更新行为：

在这种情况下，在 Gemfile(5) 中手动更新精简版本，然后运行bundle install(1)bundle-install.1.html将仅更新 >守护进程和eventmachine，但不是机架。有关详细信息，请参阅bundle install(1) bundle-install.1.html 的保守更新部分。

从 1.14 开始，指定 --conservative 选项还将阻止更新间接依赖项。

补丁级别选项

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

--patch: 最好只更新到下一个补丁版本。
--minor: 更喜欢仅更新到下一个次要版本。
--major: 优先更新到下一个主要版本（默认）。
--strict: 不允许任何 gem 更新到最新的 --patch | --次要 | --主要。

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

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

例如，如果 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 相同的任务选项。

补丁级别示例

给出以下宝石规格：

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

宝石文件：


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 上升了整个主要版本，因为现在 foo 首选小幅增加，当它达到 1.5.1 时，需要 3.0.0 的 bar。

在情况 4 中，首选 foo 直至次要版本，但 1.5.1 将不起作用，因为 --strict 标志将 bar 3.0.0 排除在考虑范围之外，因为它是一个主要增量。

在情况 5 中，由于 --strict 标志，foo 和 bar 都不再考虑任何次要或主要增量，因此它们最多可以移动到 1.4.4 和 2.0.4。