Розуміння файлу Gemfile.lock

Після запуску 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 "? Чи всі вони потрібні?

Що має містити підкаталоги ' віддалений ' та ' специфікаційний '?

Що означає знак оклику після назви дорогоцінного каменю у групі " ЗАВИСНІ "?

Ви можете дізнатися більше про це на веб-сайті постачальника (акцент додано нижче для вашої зручності):

Деякий час розробляючи свою програму, перевірте програму разом із знімком Gemfile та Gemfile.lock . Тепер у вашому сховищі є запис точних версій усіх дорогоцінних каменів, які ви використовували останній раз, коли впевнені, що програма працювала ...

Це важливо: Gemfile.lock робить вашу програму єдиним пакетом як власного коду, так і стороннього коду, який він запускався востаннє, коли ви точно знаєте, що все спрацювало. Вказання точних версій стороннього коду, від якого ви залежите у вашому Gemfile, не дасть однакової гарантії, оскільки дорогоцінні камені зазвичай декларують діапазон версій для їх залежностей.

що стосується знака оклику, я щойно дізнався, що це на дорогоцінних каменях :git, наприклад,

gem "foo", :git => "git@github.com:company/foo.git"

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

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

GEM (необов’язковий, але дуже поширений)

Це залежності, отримані від сервера Rubygems. Це може бути основний індекс Rubygems на Rubygems.org, або це може бути власний індекс, наприклад, доступний у Gemfury та інших. У цьому розділі ви побачите:

• remote: один або кілька рядків із зазначенням місця розташування індексів Rubygems
• specs: перелік залежностей із номером їх версії та обмеженнями для будь-яких додаткових залежностей

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, знайдена на цьому віддаленому пристрої, з номером його версії та обмеженнями на будь-які додаткові залежності

ПЛАТФОРМИ

Платформа Ruby, проти якої було створено Gemfile.lock. Якщо будь-які залежності в Gemfile вказують платформу, вони включатимуться в Gemfile.lock лише тоді, коли на цій платформі генерується файл блокування (наприклад, через встановлення).

ЗАЛЕЖНОСТІ

Перелік залежностей, які вказані в Gemfile, разом із обмеженням версії, вказаною там.

Залежності, визначені джерелом, відмінним від основного індексу Rubygems (наприклад, git-залежність, на основі шляху, залежності), !означають, що вони "прикріплені" до цього джерела ² (хоча іноді потрібно шукати у Gemfile, щоб визначити).

РІЗНА ВЕРСІЯ (на вибір)

Версія Ruby, зазначена в Gemfile, коли цей Gemfile.lock був створений. Якщо у .ruby_versionфайлі вказана версія Ruby, замість цього розділу цей розділ не буде (оскільки Bundler буде враховувати агностик Gemfile / Gemfile.lock до версії Ruby інсталятора).

ЗВ'ЯЗАНО З (Bundler> = v1.10.x)

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

ДЖЕРЕЛ ПЛУГІН (необов’язково і дуже рідко)

Теоретично Gemfile може вказати плагіни Bundler, а також дорогоцінні камені ³ , які потім будуть перераховані тут. На практиці я не знаю жодних доступних плагінів станом на липень 2017 року. Ця частина Bundler все ще знаходиться в активному розвитку!

1. https://dependabot.com
2. https://github.com/bundler/bundler/isissue/4631
3. http://andre.arko.net/2012/07/23/towards-a-bundler-plugin-system/

Bundler - менеджер Gem, який забезпечує послідовне середовище для Ruby-проектів, відстежуючи та встановлюючи точні дорогоцінні камені та версії, які потрібні.

Gemfile та Gemfile.lock - це основні продукти, що надаються компанією Bundler (сам Bundler - це дорогоцінний камінь).

Gemfile містить залежність вашого проекту від дорогоцінних каменів, які ви вручну згадуєте із вказаною версією, але ці вкладення коштовних каменів залежать від інших дорогоцінних каменів, які розв’язується bundler автоматично.

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

Під час першого встановлення пакета викликів він створить цей Gemfile.lock і використовує цей файл у всіх наступних викликах для встановлення пакету, що гарантує встановлення всіх залежностей та пропуск установки встановлення залежності.

Те саме відбувається, коли ви ділитесь кодом з різними машинами

Ви ділитесь своїм Gemfile.lock разом з Gemfile, коли ви запускаєте встановлення пакету на іншій машині, він буде посилатися на ваш Gemfile.lock і пропустити етап вирішення залежності, замість цього він встановить усі ті самі залежні дорогоцінні камені, які ви використовували на оригінальна машина, яка підтримує послідовність на кількох машинах

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

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

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

Також можна оновити дорогоцінні камені в Gemfile.lock за допомогою оновлення пакетів .

На цьому грунтується концепція консервативного оновлення

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

У плагіні 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) буде включати лише "july" в Gemfile.lock (а отже, і в додаток) у середовищі розробки. Тож коли ти запустишся bundle install, ти побачиш "липня" не лише під PATH, але й під ЗАВДАННЯМ, але лише в розвитку. У виробництві його взагалі не буде. Однак, коли ви використовуєте (2), ви побачите "липня" лише в PATH, а не в ЗАВИСИМОСТІ, але він з’явиться, коли ви bundle installз виробничого середовища (тобто в якійсь іншій дорогоцінній камені, яка включає вашу як залежність), а не лише розвиток.

Це лише мої спостереження, і я не можу повністю пояснити, чому все так і є, але я вітаю подальші коментарі.

Здається, немає чіткого документа, який би говорив про Gemfile.lockформат. Можливо, це тому Gemfile.lock, що просто використовується пакетом внутрішньо.

Однак, оскільки Gemfile.lockце знімок Gemfile, який означає, що вся його інформація повинна надходити Gemfile(або зі значення за замовчуванням, якщо не вказано в Gemfile).

Адже в GEMньому перераховані всі залежності, які ви вводите прямо чи опосередковано в Gemfile. remoteпід GEMрозповідає, де взяти дорогоцінні камені, що вказано джерелом у Gemfile.

Якщо дорогоцінний камінь не виймається remote, PATHповідомляє місце, щоб його знайти. PATHІнформація надходить від шляху в Gemfileпри оголошенні залежності.

І PLATFORMвід сюди .

Бо DEPENDENCIESце знімок залежностей, розв’язаний пакетом.

Що означає знак оклику після назви дорогоцінного каменю у групі "ЗАВДАННЯ"?

Знак оклику з'являється, коли дорогоцінний камінь встановлено за допомогою іншого джерела, ніж " https://rubygems.org ".