Понимание файла Gemfile.lock - PullRequest
Новая
       50

Понимание файла Gemfile.lock

172 голосов
/ 22 сентября 2011

После выполнения команды bundle install в рабочем каталоге создается 'Gemfile.lock '. Что означают директивы внутри этого файла?

Например, давайте возьмем следующий файл: 

PATH
  remote: .
  specs:
    gem_one (0.0.1)

GEM
  remote: http://example.org/
  specs:
    gem_two (0.0.2)
    gem_three (0.0.3)
      gem_four (0.0.4)

PLATFORMS
  platform

DEPENDENCIES
  gem_two
  gem_one!

Что описывают ' PATH ', ' GEM ', ' PLATFORMS ' и ' DEPENDENCIES '? Все ли они требуются?

Что должно содержать поддирективы ' remote ' и ' specs '?

Что означает восклицательный знак после названия драгоценного камня в группе ' DEPENDECIES '?

Ответы [ 7 ]

73 голосов
/ 22 сентября 2011

Подробнее об этом можно узнать на веб-сайте (для вашего удобства добавлен акцент ниже):

После некоторой разработки приложения проверьте его вместес Gemfile и Gemfile.lock снимком.Теперь в вашем хранилище есть запись точных версий всех драгоценных камней, которые вы использовали в последний раз, когда вы точно знали, что приложение работало ...

Это важно: Gemfile.lock делает ваше приложение единым пакетом как вашего собственного кода, так и стороннего кода, который он запускал в прошлый раз, когда вы точно знали, что все работает.Указание точных версий стороннего кода, от которого вы зависите, в вашем Gemfile не даст такой же гарантии, потому что гемы обычно объявляют диапазон версий для своих зависимостей.

35 голосов
/ 15 февраля 2012

в отношении восклицательного знака, который я только что обнаружил, он находится на драгоценных камнях, полученных с помощью :git, например, 

gem "foo", :git => "git@github.com:company/foo.git"
21 голосов
/ 08 июля 2017

Последние несколько месяцев я много возился с Gemfiles, и Gemfile.locks много занимался созданием автоматизированного инструмента обновления зависимостей 1 .Ниже далеко не все, но это хорошая отправная точка для понимания формата Gemfile.lock.Вы также можете проверить исходный код для парсера файла блокировки Bundler .

В файле блокировки, сгенерированном Bundler 1.x, вы найдете следующие заголовки:

GEM (необязательно, но очень часто)

Это зависимости, полученные из сервера Rubygems.Это может быть основной индекс Rubygems на Rubygems.org или пользовательский индекс, например, доступный в Gemfury и других.В этом разделе вы увидите:

  • remote: одну или несколько строк, указывающих расположение индекса (ов) Rubygems
  • specs: список зависимостей с ихномер версии и ограничения на любые подчиненные зависимости

GIT (необязательно)

Это зависимости, полученные из данного удаленного git.Вы увидите разные разделы для каждого git-пульта, а внутри каждого раздела вы увидите:

  • remote: git-пульта.Например, git@github.com:rails/rails
  • revision: ссылка на фиксацию Gemfile.lock заблокирована для
  • tag: (необязательно) тега, указанного в Gemfile
  • specs: git-зависимость, найденная на этом удаленном компьютере, с номером версии и ограничениями на любые подзависимости

PATH (необязательно)

Это зависимости, полученные изданное path, предоставленное в Gemfile.Вы увидите различный из этих разделов для каждой зависимости пути, и внутри каждого раздела вы увидите:

  • remote: путь.Например, plugins/vendored-dependency
  • specs: зависимость git, найденная на этом удаленном компьютере, с номером версии и ограничениями на любые подчиненные зависимости

PLATFORMS

Платформа Ruby, против которой был создан Gemfile.lock.Если какие-либо зависимости в Gemfile указывают платформу, они будут включены в Gemfile.lock только при создании файла блокировки на этой платформе (например, посредством установки).

DEPENDENCIES

Список зависимостей, указанных в Gemfile, вместе с указанным там ограничением версии.

Зависимости, указанные с источником, отличным от основного индекса Rubygems (например, зависимости git,основанные на пути, зависимости) имеют !, что означает, что они "прикреплены" к этому источнику 2 (хотя иногда нужно искать в Gemfile, чтобы определить, в каком).

RUBY VERSION (необязательно)

Версия Ruby, указанная в Gemfile, когда был создан этот Gemfile.lock.Если вместо этого в файле .ruby_version указана версия Ruby, этот раздел не будет представлен (так как Bundler будет рассматривать Gemfile / Gemfile.lock независимо от версии Ruby установщика).

BUNDLED WITH (Bundler> = v1.10.x)

Версия Bundler, использованная для создания Gemfile.lock.Используется для напоминания установщикам обновить свою версию Bundler, если она старше, чем версия, создавшая файл.

PLUGIN SOURCE (необязательно и очень редко)

InВ теории Gemfile может указывать плагины Bundler, а также гемы 3 , которые затем будут перечислены здесь.На практике я не знаю ни о каких доступных плагинах по состоянию на июль 2017 года. Эта часть Bundler все еще находится в активной разработке!

  1. https://dependabot.com
  2. https://github.com/bundler/bundler/issues/4631
  3. http://andre.arko.net/2012/07/23/towards-a-bundler-plugin-system/
8 голосов
/ 21 февраля 2016

Bundler - менеджер Gem, который обеспечивает согласованную среду для проектов Ruby, отслеживая и устанавливая точные гемы и версии, которые необходимы.

Gemfile и Gemfile.lock являются основными продуктами, предоставляемыми Gem Bundler (сам Bundler является гемом).

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

Gemfile.lock содержит полный снимок всех драгоценных камней в Gemfile вместе с соответствующей зависимостью.

Когда вы в первый раз вызываете bundle install , он создаст этот Gemfile.lock и использует этот файл во всех последующих вызовах для установки bundle, что гарантирует, что у вас установлены все зависимости, и пропустит установку зависимостей.

То же самое происходит, когда вы делитесь своим кодом на разных машинах

Вы делитесь своим Gemfile.lock вместе с Gemfile. Когда вы запускаете bundle install на другом компьютере, он ссылается на ваш Gemfile.lock и пропускает шаг разрешения зависимостей, вместо этого он устанавливает все те же самые зависимые гемы, которые вы используется на исходной машине, которая поддерживает согласованность на нескольких машинах

Почему нам необходимо поддерживать согласованность на нескольких машинах?

  • Запуск разных версий на разных машинах может привести к поломке код

  • Предположим, ваше приложение использовало версию 1.5.3, и оно работает 14 месяцев назад
    без проблем, и вы пытаетесь установить на другую машину
    без Gemfile.lock теперь вы получаете версию 1.5.8. Может быть, это сломано с последней версией некоторых драгоценных камней и ваше приложение будет
    потерпеть поражение. Поддержание согласованности имеет первостепенное значение (предпочтительно
    практика).

Также можно обновить gem в Gemfile.lock, используя обновление пакета .

Это основано на концепции консервативного обновления

8 голосов
/ 21 сентября 2012

Мне кажется, что PATH перечисляет зависимости первого поколения непосредственно из вашей gemspec, тогда как GEM перечисляет зависимости второго поколения (то есть, от чего зависят ваши зависимости) и зависимости из вашего Gemfile. PATH :: remote - ., потому что он полагался на локальную gemspec в текущем каталоге, чтобы выяснить, что принадлежит PATH :: spec, тогда как GEM :: remote - rubygems.org, так как именно туда он должен был пойти, чтобы выяснить, что принадлежит в GEM :: spec.

В плагине Rails вы увидите раздел PATH, но не в приложении Rails. Поскольку в приложении нет файла gemspec, нечего было бы вставлять в PATH.

Что касается ЗАВИСИМОСТИ, gembundler.com сообщает: 

Runtime dependencies in your gemspec are treated like base dependencies, 
and development dependencies are added by default to the group, :development

Gemfile, сгенерированный rails plugin new my_plugin, говорит что-то похожее: 

# Bundler will treat runtime dependencies like base dependencies, and
# development dependencies will be added by default to the :development group.

Это означает, что разница между 

s.add_development_dependency "july" # (1)

и 

s.add_dependency "july" # (2)

заключается в том, что (1) будет включать «июль» только в Gemfile.lock (и, следовательно, в приложение) в среде разработки. Поэтому, когда вы запустите bundle install, вы увидите «июль» не только в PATH, но и в ЗАВИСИМОСТИ, но только в разработке. В производстве его не будет вообще. Тем не менее, когда вы используете (2), вы увидите «июль» только в PATH, а не в ЗАВИСИМОСТИ, но он будет отображаться, когда вы bundle install из производственной среды (то есть в каком-то другом геме, который включает ваш в качестве зависимости). ), не только разработка.

Это всего лишь мои наблюдения, и я не могу полностью объяснить, почему так происходит, но я приветствую дальнейшие комментарии.

1 голос
/ 09 сентября 2016

Кажется, нет четкого документа, говорящего в формате Gemfile.lock. Возможно, это связано с тем, что Gemfile.lock используется внутренне для связки.

Однако, поскольку Gemfile.lock является снимком Gemfile, что означает, что вся его информация должна поступать из Gemfile (или из значения по умолчанию, если оно не указано в Gemfile).

Для GEM в нем перечислены все зависимости, которые вы прямо или косвенно вводите в Gemfile. remote в GEM указывает, где взять драгоценные камни, что указано source в Gemfile.

Если камень не извлечен из remote, PATH сообщает локации, где его найти. PATH информация берется из path в Gemfile, когда вы объявляете зависимость.

И PLATFORM от здесь .

Для DEPENDENCIES - это снимок зависимостей, разрешенных с помощью пакета.

0 голосов
/ 06 января 2016

Что означает восклицательный знак после имени драгоценного камня в группе 'ЗАВИСИМОСТЬ'?

Восклицательный знак появляется, когда драгоценный камень был установлен с использованием источника, отличного от "https://rubygems.org".

...