Чи повинен я вказати точні версії у своєму Gemfile?

Question 1

Я помітив, що на rubygems.org багато дорогоцінних каменів пропонують вказувати їх за основною версією, а не за точною версією. Наприклад...

Перлина hamm-rails ...

gem "haml-rails", "~> 0.3.4"  # "$ bundle install" will acquire the 
                              # latest version before 1.0.

Однак, базуючись на документах Bundler, мені здалося, що було б краще зафіксувати саме таку версію ...

gem "haml-rails", "0.3.4"

Отже, є ваш дорогоцінний камінь haml-rails, і всі його залежності не змістяться вперед. Якщо ви перевірите проект на іншій машині через кілька тижнів і запустите, у $ bundle installвас будуть точно такі ж версії всього, що ви вказали.

Я бачив точкові випуски, що розбивають речі, і я думав, що частиною цілої ідеї Bundler було " Bundle.lock" створення всіх ваших версій для самоцвітів.

Але на rubygems.org вони часто використовують "~>", тому, можливо, я чогось пропускаю?

Будь-яке роз'яснення було б дуже корисним для мене в розумінні Bundler та управління коштовностями.

Question 2

Це мета файлу Gemfile.lock - запуск bundle installіз Gemfile.lock присутній лише для встановлення з використанням перелічених там залежностей; це не вирішує Gemfile. Щоб оновити залежності / оновити версії gem, вам потрібно явно зробити a bundle update, який оновить ваш файл Gemfile.lock.

Якби не було Gemfile.lock, розгортання коду на виробництві було б основною проблемою, оскільки, як ви вже згадували, залежності та версії gem можуть змінитися.

Коротше кажучи, ви повинні бути в цілому в безпеці, використовуючи песимістичний оператор обмеження версії ( ~>), як радить rubygems.org. Тільки не забудьте повторно запустити тести після того, як зробите, bundle updateщоб переконатися, що нічого не зламалося.

Є приємна стаття Єгуди Каца, де є трохи більше інформації про Gemfile.lock.

Question 3

TL; DR

Так, використовуйте песимістичний замок ( ~>) і вкажіть семантичну версію до патчу ( Major.minor.patch) на всіх своїх дорогоцінних каменях!

Обговорення

Я здивований недостатньою ясністю щодо цього питання, навіть "експерти галузі" днями сказали мені, що Gemfile.lockіснує для підтримки версій самоцвітів. Неправильно!

Ви хочете організувати свій Gemfileспосіб таким чином, щоб ви могли бігати bundle updateбудь-коли, не ризикуючи зламати все. Щоб досягти цього:

Вкажіть версію на рівні патча для всіх ваших дорогоцінних каменів з песимістичним блокуванням. Це дозволить bundle updateотримувати виправлення, але не порушувати зміни.
Вкажіть refдля gems від git

Єдиним недоліком цієї установки є те, що коли виходить солодка нова мінорна / мажорна версія для дорогоцінного каміння, вам доведеться піднімати версію вручну.

Сценарій попередження

Поміркуйте, що станеться, якщо ви не заблокуєте свої дорогоцінні камені.
У вас є розблокований gem "rails"в вашому Gemfile і версії в Gemfile.lockIS 4.1.16. Ви кодуєте, і в якийсь момент ви робите a bundle update. Тепер ваша версія Rails переходить до 5.2.0(за умови, що інший камінь не заважає цьому) і все ламається.
Зробіть собі послугу і не дозволяйте цього жодному самоцвіту!

Приклад Gemfile

# lock that bundler
if (version = Gem::Version.new(Bundler::VERSION)) < Gem::Version.new('1.16.3')
  abort "Bundler version >= 1.16.3 is required. You are running #{version}"
end

source "http://rubygems.org"

# specify explicit ref for git repos
gem "entity_validator",
  git: "https://github.com/plataformatec/devise",
  ref: "acc45c5a44c45b252ccba65fd169a45af73ff369" # "2018-08-02"

# consider hard-lock on gems you do not want to change one bit
gem "rails", "5.1.5"

# pessimistic lock on your common gems
gem "newrelic_rpm", "~> 4.8.0"
gem "puma", "~> 3.12.0"

group :test do
  gem "simplecov", "~> 0.16.1", require: false
end

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

gem "puma", "~> 3.12"

Question 4

Я б точно сказав, використовуйте точні номери версій. Можливо, ви завжди можете просто заблокувати його до основної версії або ніколи не вказувати будь-яку версію, і все буде в порядку, але якщо ви дійсно хочете, щоб цей тонкодисперсний рівень контролю і мав 100% впевненість у своїй програмі під час запуску на інших машинах, використовуйте точні номери версій.

Я траплявся в ситуаціях, коли не був вказаний точний номер версії, і коли я чи хтось інший робив це bundle install, проект зламався, оскільки він перейшов на новішу версію. Це може бути особливо погано при розгортанні на виробництві.

Bundler дійсно замикає ваші специфікації дорогоцінного каменя, але якщо ви кажете йому просто використовувати основний випуск, то він блокує це. Так само знає: "О, версія заблокована на> 0,1" або що завгодно, але не "О версія заблокована спеціально на 0.1.2.3 ".