Dois-je spécifier les versions exactes dans mon Gemfile ?

Question

J'ai remarqué que sur rubygems.org beaucoup de gemmes suggèrent que vous les spécifiez par version majeure plutôt que par version exacte. Par exemple...

Le joyau du jambon-rails ...

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

Cependant, sur la base de la Documentation sur le Bundler il me semblait qu'il serait préférable de déterminer la version exacte comme ceci...

gem "haml-rails", "0.3.4"

Voilà donc votre gemme haml-rails et toutes ses dépendances ne dériveront pas vers l'avant. Si vous vérifiez le projet sur une autre machine quelques semaines plus tard et exécutez $ bundle install vous aurez exactement les mêmes versions de tout ce que vous avez spécifié.

J'ai vu des versions ponctuelles casser des choses, et je pensais qu'une partie de l'idée de Bundler était de " Bundle.lock " toutes vos versions de gemmes.

Mais sur rubygems.org ils utilisent beaucoup "~>" alors peut-être que je manque quelque chose ?

Toute clarification me serait très utile pour comprendre Bundler et la gestion des gemmes.

Answer 1

C'est le but du fichier Gemfile.lock - exécuter bundle install avec un Gemfile.lock présent n'installe qu'en utilisant les dépendances qui y sont listées ; il ne résout pas le Gemfile. Pour mettre à jour les dépendances / mettre à jour les versions des gemmes, vous devez alors explicitement faire un bundle update qui mettra à jour votre fichier Gemfile.lock.

S'il n'y avait pas de Gemfile.lock, le déploiement du code en production serait un problème majeur car, comme vous le mentionnez, les dépendances et les versions des gemmes pourraient changer.

En bref, vous devriez être généralement en sécurité en utilisant l'opérateur de contrainte de version pessimiste ( ~> ) comme rubygems.org le conseille. Assurez-vous simplement de réexécuter vos tests après avoir fait un bundle update pour s'assurer que rien ne se casse.

Il y a un bel article par Yehuda Katz qui a un peu plus d'informations sur Gemfile.lock.

Answer 2

TL;DR

Oui, utilisez verrouillage pessimiste ( ~> ) et spécifier un version sémantique jusqu'à la parcelle ( Major.minor.patch ) sur tous vos joyaux !

Discussion

Je suis surpris par le manque de clarté sur cette question, même les "experts du secteur" m'ont dit l'autre jour que Gemfile.lock est là pour maintenir les versions des gemmes. C'est faux !

Vous voulez organiser votre Gemfile de manière à ce que vous puissiez exécuter bundle update à tout moment sans risquer de tout casser. Pour y parvenir :

1. Spécifiez une version de niveau patch pour toutes vos gemmes avec un verrouillage pessimiste. Ceci permettra bundle update pour vous donner des correctifs, mais pas de changements de rupture.

2. Indiquez un ref pour les gemmes de git

Le seul inconvénient de cette configuration est que lorsqu'une nouvelle version mineure/majeure d'une gemme est publiée, vous devez mettre la version à jour manuellement.

Scénario d'alerte

Pensez à ce qui se passe si vous ne verrouillez pas vos pierres précieuses.
Vous avez un appareil non verrouillé gem "rails" dans votre gemfile et la version dans Gemfile.lock es 4.1.16 . Vous êtes en train de coder et à un moment donné, vous faites un bundle update . Maintenant, votre version de Rails passe à 5.2.0 (à condition qu'une autre gemme ne l'empêche pas) et tout se casse la figure.
Faites-vous une faveur et ne permettez pas cela pour n'importe quel bijou !

Un exemple de 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

Une concession
Si vous êtes sûr que vos tests vont attraper les bogues introduits par les changements de version des gemmes, vous pouvez essayer de verrouiller les gemmes de façon pessimiste à la version mineure, et non au patch.
Cela permettra à la version de la gemme d'augmenter dans la version majeure spécifiée, mais jamais dans la suivante.

gem "puma", "~> 3.12"

Answer 3

Je dirais certainement d'utiliser les numéros de version exacts. Vous pouvez probablement toujours vous contenter d'une version majeure, ou ne jamais spécifier de version, et tout ira bien, mais si vous voulez vraiment ce niveau de contrôle fin et avoir une confiance totale dans votre programme lorsqu'il est exécuté sur d'autres machines, utilisez les numéros de version exacts.

J'ai été dans des situations où le numéro de version exact n'était pas spécifié, et quand moi ou quelqu'un d'autre a fait une bundle install le projet s'est cassé parce qu'il est passé à une version plus récente. Cela peut être particulièrement grave lors du déploiement en production.

Regroupement fait verrouille les spécifications de vos gemmes, mais si vous lui demandez d'utiliser une version majeure, il le fait. Donc il sait juste "Oh la version est verrouillée à > 0.1" ou autre, mais pas "Oh la version est verrouillée spécifiquement à 0.1.2.3".