Ответы:
Здесь Gemfile
вы указываете, какие драгоценные камни хотите использовать, и позволяет указать, какие версии.
В этом Gemfile.lock
файле Bundler записывает точные версии, которые были установлены. Таким образом, когда та же библиотека / проект загружается на другой компьютер, при запуске bundle install
будут просматриваться Gemfile.lock
и устанавливаться точно такие же версии, а не просто использовать Gemfile
и устанавливать самые последние версии. (Запуск разных версий на разных машинах может привести к сбоям в тестах и т. Д.) Вам никогда не придется напрямую редактировать файл блокировки.
Ознакомьтесь с целью и обоснованием Bundler , особенно с разделом «Проверка кода в системе контроля версий».
Обычно мы пишем зависимости в Gemfile как:
gem "nokogiri", "~> 1.4.4"
gem 'bcrypt-ruby', '~> 3.0.0'
gem 'uglifier', '>= 1.2.3'
..
Здесь вы в основном говорите: « Я хочу nokogiri, если он выше версии 1.4.4 » и т. Д. Теперь предположим, что я настроил свое Gemfile
8 месяцев назад и успешно настроил свое приложение с этим требованием. 8 месяцев назад версия nokogiri была 1.4.4 . Мои приложения rails работали отлично, без проблем с этой версией.
Теперь подумайте, что я пытаюсь построить то же самое Gemfile
. Но если мы посмотрим на версии nokogiri, то увидим, что текущая стабильная версия изменилась на 1.4.9 . Это означает, что если мы попытаемся собрать, сборщик установит версию 1.4.9 nokogiri (предположим, что у нас ее нет Gemfile.lock
).
Как видите, если у вас их нет, Gemfile.lock
запустите:
bundle install
тогда используемые в настоящее время драгоценные камни могут быть разными в любое время . Ваше приложение использовало версию 1.4.4 и работает 8 месяцев назад без каких-либо проблем, но если вы попытаетесь собрать его сейчас, вы получите версию 1.4.9 . Возможно, он не работает в последней версии nokogiri
, замечательная функция, которую вы использовали с 1.4.4, больше недоступна и т. Д.
Для предотвращения такого рода проблем Gemfile.lock
используется. В написаны Gemfile.lock
только точные версии и поэтому будут установлены только они. Это означает, что если вы распространяете свое приложение с помощью Gemfile.lock
, на каждой машине будут установлены одни и те же драгоценные камни, и, что наиболее важно, все они получат одну и ту же версию . Это даст вам стабильный и общий стек развертывания.
Он автоматически создается с первым:
bundle install
команда. После этого каждый раз при запуске bundle install
пакет сначала ищет Gemfile.lock
и устанавливает указанные там драгоценные камни. Распространять этот файл среди своих проектов - это привычка, чтобы обеспечить стабильность и стабильность.
Если вас устраивает последняя версия ваших приложений, вы можете обновить ее Gemfile.lock
. Просто отразите свои изменения в Gemfile
. Это означает изменение зависимостей на новые точные версии в Gemfile
. После этого запустите:
bundle install
Это обновит вас до Gemfile.lock
последней версии приложений.
nokogiri ~> 1.4.4
не позволяет 1.5.3
установить; максимально допустимый будет 1.4.x
где x>=4
(для нокогири это будет 1.4.7
). В ~>
оператор означает только последняя цифра в использованную драгоценный камень может быть «больше» данной версии. Например, foo ~> a.b.c.d
означает , что подойдет любая версия, foo
если она все еще abc {something} where {something} >=
d. См. Также связанный вопрос
gem "nokogiri", "~> 1.4.4"
в gemfile. Почему сборщик не мог просто использовать эту версию? Это потому, что он предназначен для намеренной установки последних версий гема по умолчанию?
~> 1.4.4
эквивалентно >= 1.4.4 and < 1.5
. См. Bundler.io/v1.5/gemfile.html . Для точной версии просто используйте gem 'foo', '1.4.4'
.
bundle install
будет проверяться, Gemfile
даже если есть, Gemfile.lock
и вводиться новые ограничения Gemfile.lock
?
Gemfile.lock
Когда вы запускаете установку пакета, Bundler сохранит полные имена и версии всех используемых гемов (включая зависимости гемов, указанных в Gemfile (5)) в файле с именем Gemfile.lock.
Bundler использует этот файл во всех последующих вызовах установки пакета, что гарантирует, что вы всегда будете использовать один и тот же точный код, даже когда ваше приложение перемещается между машинами.
Из-за того, как работает разрешение зависимостей, даже кажущееся небольшое изменение (например, обновление до момента выпуска зависимости гема в вашем Gemfile (5)) может привести к тому, что для удовлетворения всех зависимостей потребуются радикально разные драгоценные камни.
В результате вам СЛЕДУЕТ проверить свой Gemfile.lock в системе контроля версий. Если вы этого не сделаете, каждая машина, которая проверяет ваш репозиторий (включая ваш производственный сервер), снова разрешит все зависимости, что приведет к использованию разных версий стороннего кода, если какой-либо из драгоценных камней в Gemfile (5) или любой другой их зависимости были обновлены.
Gemfile.lock
в некоторых случаях (например,rails (4.0.0)
требуетbundler (>= 1.3.0, < 2.0)
) включаются «открытые» версии , что вызывает проблемы. Есть идеи, как избежать этих «открытых» зависимостей?