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]

ОПИСАНИЕ

Обновите указанные гемы (все гемы, если используется флаг --all), игнорируя ранее установленные гемы, указанные в Gemfile.lock. Как правило, вы должны использовать пакетную установку (1) bundle-install.1.html для установки одних и тех же гемов и версий на разных компьютерах.

Вы должны использовать обновление пакета, чтобы явно обновить версию драгоценного камня.

ПАРАМЕТРЫ

--all: Обновите все гемы, указанные в Gemfile.
--group=<name>, -g=[<name>]: Обновляйте только драгоценные камни в указанной группе. Например, вы можете обновить все гемы в группе разработки с помощью bundle update --group development. Вы также можете вызвать bundle update rails --group test, чтобы, например, обновить гем rails и все гемы в тестовой группе.
--source=<name>: Имя источника :git или :path, используемого в Gemfile(5). Например, с источником :git http://github.com/rails/rails.git вы должны вызвать bundle update --source rails
--local: Не пытайтесь получить драгоценные камни удаленно и вместо этого используйте кеш драгоценных камней.
--ruby: Обновите заблокированную версию Ruby до текущей версии Ruby.
--bundler: Обновите заблокированную версию упаковщика до версии вызываемого упаковщика.
--full-index: Вернитесь к использованию однофайлового индекса всех драгоценных камней.
--jobs=[<number>], -j[<number>]: Укажите количество заданий для параллельного выполнения. По умолчанию используется количество доступных процессоров.
--retry=[<number>]: Повторите неудачные сетевые или Git-запросы количество раз.
--quiet: Выводить только предупреждения и ошибки.
--redownload: Принудительная загрузка каждого драгоценного камня.
--patch: Предпочитаю обновление только до следующей версии патча.
--minor: Предпочитаю обновление только до следующей минорной версии.
--major: Предпочитаете обновление до следующей основной версии (по умолчанию).
--strict: Не разрешать обновлять гем после последнего --patch | --второстепенный | --основной.
--conservative: Используйте консервативное поведение при установке пакета и не допускайте обновления косвенных зависимостей.

ОБНОВЛЕНИЕ ВСЕХ КАМНЕЙ

Если вы запустите bundle update --all, сборщик проигнорирует все ранее установленные драгоценные камни и снова разрешит все зависимости на основе последних версий всех драгоценных камней, доступных в источниках.

Рассмотрим следующий Gemfile(5):

source "https://rubygems.org"

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

Когда вы запускаете пакет install(1) bundle-install.1.html в первый раз, пакет разрешает все зависимости до самого низа и устанавливает то, что вам нужно:

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), вашему приложению для работы требуется 26 разных геев. Bundler запоминает точные версии, которые он установил в Gemfile.lock. В следующий раз, когда вы запустите пакет install(1) bundle-install.1.html, пакет пропустит разрешение зависимостей и установит те же гемы, что и в прошлый раз.

После регистрации Gemfile.lock в системе управления версиями и клонирования его на другом компьютере запуск пакета install(1) bundle-install.1.html будет по-прежнему установите гемы, которые вы установили в прошлый раз. Вам не нужно беспокоиться о том, что новый выпуск erubis или mail изменит используемые вами драгоценные камни.

Однако время от времени вы можете захотеть обновить используемые вами драгоценные камни до новейших версий, которые все еще соответствуют драгоценным камням в вашем Gemfile(5).

Для этого запустите bundle update --all, который проигнорирует Gemfile.lock и снова разрешит все зависимости. Имейте в виду, что этот процесс может привести к значительному изменению набора из 25 драгоценных камней в зависимости от требований к новым драгоценным камням, которые авторы драгоценных камней выпустили с момента последнего запуска bundle update --all.

ОБНОВЛЕНИЕ СПИСКА КАМНЕЙ

Иногда вы хотите обновить один гем в Gemfile(5) и оставить остальные гемы, указанные вами, привязанными к версиям в Gemfile.lock.

Например, в приведенном выше сценарии представьте, что nokogiri выпускает версию 1.4.4, и вы хотите обновить ее, без обновления Rails и всего его зависимости. Для этого запустите пакетное обновление nokogiri.

Bundler будет обновлять nokogiri и все его зависимости, но не трогать Rails и его зависимости.

ПЕРЕКРЫВАЮЩИЕСЯ ЗАВИСИМОСТИ

Иногда несколько драгоценных камней, объявленных в вашем Gemfile(5), удовлетворяются одной и той же зависимостью второго уровня. Например, рассмотрим случай thin и rack-perftools-profiler.

source "https://rubygems.org"

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

Gem thin зависит от 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)

В этом случае у двух драгоценных камней есть собственный набор зависимостей, но у них общая стойка. Если вы запустите bundle update thin, пакет обновит демоны, eventmachine и rack, которые являются зависимостями >thin, но не open4 или perftools.rb, которые являются зависимостями rack-perftools_profiler. Обратите внимание, что bundle update thin будет обновлять rack, хотя это также зависит от rack-perftools_profiler.

Короче говоря, по умолчанию, когда вы обновляете гем с помощью bundle update, сборщик обновляет все зависимости этого гем, включая те, которые также являются зависимостями другого гем.

Чтобы предотвратить обновление косвенных зависимостей, до версии 1.14 единственным вариантом было поведение КОНСЕРВАТИВНОЕ ОБНОВЛЕНИЕ в пакетной установке(1) bundle-install.1.html:

В этом сценарии обновление тонкой версии вручную в Gemfile(5), а затем запуск пакета install(1) bundle-install.1.html обновит только daemons и eventmachine, но не rack. Дополнительные сведения см. в разделе КОНСЕРВАТИВНОЕ ОБНОВЛЕНИЕ в пакетной установке(1) bundle-install.1.html.

Начиная с версии 1.14, указание параметра --conservative также предотвратит обновление косвенных зависимостей.

ВАРИАНТЫ УРОВНЯ ПАТЧА

Версия 1.14 представила 4 параметра уровня исправления, которые будут влиять на то, как разрешаются версии гемов. Можно использовать один из следующих вариантов: --patch, --minor или --major. --strict можно добавить для дальнейшего влияния на разрешение.

--patch: Предпочитаю обновление только до следующей версии патча.
--minor: Предпочитаю обновление только до следующей минорной версии.
--major: Предпочитаете обновление до следующей основной версии (по умолчанию).
--strict: Не разрешать обновлять гем после последнего --patch | --второстепенный | --основной.

Когда Bundler решает, какие версии использовать для удовлетворения заявленных требований в Gemfile или в родительских гемах, он просматривает все доступные версии, отфильтровывает все версии, которые не удовлетворяют требованиям, а затем по умолчанию сортирует их от самых новых до самые старые, рассматривая их в таком порядке.

Предоставление одного из параметров уровня исправления (например, --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, по умолчанию порядок предпочтения по умолчанию (--основной) будет "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 с любым параметром уровня исправления удалит все версии, выходящие за рамки параметра уровня исправления, чтобы гарантировать, что ни один гем не будет обновлен до такой степени.

Продолжая предыдущий пример, если используются обе опции --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".

Требования Gem, определенные в Gemfile, по-прежнему будут первым определяющим фактором для доступных версий. Если требование гема для foo в Gemfile равно '~> 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

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 поднимается на весь основной релиз, потому что теперь для foo предпочтительнее незначительное увеличение, а когда он доходит до 1.5.1, требуется 3.0.0 bar.

В случае 4, foo предпочтительнее до младших версий, но 1.5.1 не будет работать, потому что флаг --strict удаляет бар 3.0.0 из рассмотрения, так как это основное приращение.

В случае 5 и для foo, и для bar любые малые или большие приращения исключены из рассмотрения из-за флага --strict, поэтому максимум, что они могут перемещать, это до 1.4.4 и 2.0.4.