Comprendre le fichier Gemfile.lock

Après avoir exécuté la bundle installcommande, «Gemfile.lock » est créé dans le répertoire de travail. Que signifient les directives dans ce fichier?

Par exemple, prenons le fichier suivant:

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!

Que décrivent « CHEMIN », « GEM », « PLATEFORMES » et « DÉPENDANCES »? Tous sont-ils obligatoires?

Que doit contenir les sous- directives « remote » et « specs »?

Que signifie le point d'exclamation après le nom de la gemme dans le groupe « DÉPENDANCES »?

Vous pouvez en savoir plus sur le site Web du bundler (emphase ajoutée ci-dessous pour votre commodité):

Après avoir développé votre application pendant un moment, archivez l'application avec l' instantané Gemfile et Gemfile.lock . Maintenant, votre référentiel a un enregistrement des versions exactes de toutes les gemmes que vous avez utilisées la dernière fois que vous savez avec certitude que l'application a fonctionné ...

Ceci est important: le Gemfile.lock fait de votre application un package unique à la fois de votre propre code et du code tiers qu'il a exécuté la dernière fois que vous savez avec certitude que tout a fonctionné. Spécifier des versions exactes du code tiers dont vous dépendez dans votre Gemfile ne fournirait pas la même garantie, car les gemmes déclarent généralement une plage de versions pour leurs dépendances.

en ce qui concerne le point d'exclamation, je viens de découvrir que c'est sur des gemmes récupérées via :git, par exemple

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

J'ai passé les derniers mois à jouer avec Gemfiles et Gemfile.locks tout en créant un outil de mise à jour automatisée des dépendances ¹ . Ce qui suit est loin d'être définitif, mais c'est un bon point de départ pour comprendre le format Gemfile.lock. Vous pouvez également consulter le code source de l' analyseur de fichiers de verrouillage de Bundler .

Vous trouverez les en-têtes suivants dans un fichier de verrouillage généré par Bundler 1.x:

GEM (facultatif mais très courant)

Ce sont des dépendances provenant d'un serveur Rubygems. Cela peut être le principal index Rubygems, sur Rubygems.org, ou il peut s'agir d'un index personnalisé, comme ceux disponibles chez Gemfury et d'autres. Dans cette section, vous verrez:

• remote: une ou plusieurs lignes spécifiant l'emplacement du ou des index Rubygems
• specs: une liste de dépendances, avec leur numéro de version, et les contraintes sur toutes les sous-dépendances

GIT (facultatif)

Ce sont des dépendances provenant d'une télécommande git donnée. Vous verrez une de ces sections différente pour chaque git remote, et dans chaque section, vous verrez:

• remote:la télécommande git. Par exemple,git@github.com:rails/rails
• revision: la référence de validation sur laquelle le Gemfile.lock est verrouillé
• tag: (optionnel) la balise spécifiée dans le Gemfile
• specs: la dépendance git trouvée sur cette télécommande, avec son numéro de version et les contraintes sur toutes les sous-dépendances

PATH (facultatif)

Ce sont des dépendances provenant d'un pathfichier donné , fourni dans le Gemfile. Vous verrez une section différente pour chaque dépendance de chemin, et dans chaque section, vous verrez:

• remote:le chemin. Par exemple,plugins/vendored-dependency
• specs: la dépendance git trouvée sur cette télécommande, avec son numéro de version et les contraintes sur toutes les sous-dépendances

PLATEFORMES

La plate-forme Ruby sur laquelle Gemfile.lock a été généré. Si des dépendances dans le Gemfile spécifient une plate-forme, elles ne seront incluses dans Gemfile.lock que lorsque le fichier de verrouillage est généré sur cette plate-forme (par exemple, via une installation).

DEPENDANCES

Une liste des dépendances qui sont spécifiées dans le Gemfile, ainsi que la contrainte de version qui y est spécifiée.

Les dépendances spécifiées avec une source autre que l'index principal Rubygems (par exemple, les dépendances git, basées sur les chemins, les dépendances) ont un !qui signifie qu'elles sont "épinglées" à cette source ² (bien qu'il faille parfois chercher dans le Gemfile pour déterminer dans).

VERSION RUBIS (facultatif)

La version Ruby spécifiée dans le Gemfile, lors de la création de ce Gemfile.lock. Si une version Ruby est spécifiée dans un .ruby_versionfichier à la place, cette section ne sera pas présente (car Bundler considérera le Gemfile / Gemfile.lock agnostique à la version Ruby de l'installateur).

ENSEMBLE AVEC (Bundler> = v1.10.x)

La version de Bundler utilisée pour créer le Gemfile.lock. Utilisé pour rappeler aux installateurs de mettre à jour leur version de Bundler, si elle est antérieure à la version qui a créé le fichier.

PLUGIN SOURCE (optionnel et très rare)

En théorie, un Gemfile peut spécifier des plugins Bundler, ainsi que des gems ³ , qui seraient alors listés ici. En pratique, je ne connais aucun plug-in disponible, en juillet 2017. Cette partie de Bundler est toujours en développement actif!

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/

Bundler est un gestionnaire de gemmes qui fournit un environnement cohérent pour les projets Ruby en suivant et en installant les gemmes exactes et les versions nécessaires.

Gemfile et Gemfile.lock sont les principaux produits fournis par Bundler gem (Bundler lui-même est un bijou).

Gemfile contient la dépendance de votre projet vis-à-vis des gemmes, que vous mentionnez manuellement avec la ou les versions spécifiées, mais ces gemmes à leur tour dépendent d'autres gemmes qui sont résolues automatiquement par le bundler.

Gemfile.lock contient un instantané complet de tous les gemmes dans Gemfile avec leur dépendance associée.

Lorsque vous appelez pour la première fois l' installation de bundle , il créera ce Gemfile.lock et l'utilisera dans tous les appels ultérieurs à l'installation de bundle, ce qui garantit que toutes les dépendances sont installées et ignorera l'installation des dépendances.

La même chose se produit lorsque vous partagez votre code avec différentes machines

Vous partagez votre Gemfile.lock avec Gemfile, lorsque vous exécutez l'installation du bundle sur une autre machine, il fera référence à votre Gemfile.lock et sautera l'étape de résolution des dépendances, au lieu de cela, il installera tous les mêmes gemmes dépendants que vous avez utilisés sur le machine d'origine, qui maintient la cohérence entre plusieurs machines

Pourquoi avons-nous besoin de maintenir la cohérence sur plusieurs machines?

• L'exécution de différentes versions sur différentes machines peut entraîner un code cassé

• Supposons que votre application ait utilisé la version 1.5.3 et qu'elle fonctionne il y a 14 mois
  sans aucun problème, et que vous essayez d'installer sur une machine différente
  sans Gemfile.lock maintenant vous obtenez la version 1.5.8. Peut-être qu'il est cassé avec la dernière version de certains gemmes et que votre application
  échouera. Le maintien de la cohérence est de la plus haute importance (
  pratique préférée ).

Il est également possible de mettre à jour les gemmes dans Gemfile.lock en utilisant la mise à jour du bundle .

Ceci est basé sur le concept de mise à jour conservatrice

Il me semble que PATH répertorie les dépendances de première génération directement à partir de votre gemspec, alors que GEM répertorie les dépendances de deuxième génération (c'est-à-dire de quoi dépendent vos dépendances) et celles de votre Gemfile. PATH :: remote est .dû au fait qu'il s'appuyait sur une gemspec locale dans le répertoire courant pour savoir ce qui appartient à PATH :: spec, alors que GEM :: remote l'est rubygems.org, car c'est là qu'il fallait aller pour savoir ce qui appartient à GEM :: spec.

Dans un plugin Rails, vous verrez une section PATH, mais pas dans une application Rails. Étant donné que l'application n'a pas de fichier gemspec, il n'y aurait rien à mettre dans PATH.

En ce qui concerne les DÉPENDANCES, gembundler.com déclare:

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

Le Gemfile généré par rails plugin new my_plugindit quelque chose de similaire:

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

Cela signifie que la différence entre

s.add_development_dependency "july" # (1)

et

s.add_dependency "july" # (2)

est que (1) n'inclura que "juillet" dans Gemfile.lock (et donc dans l'application) dans un environnement de développement. Ainsi, lorsque vous exécutez bundle install, vous verrez "juillet" non seulement sous PATH mais aussi sous DEPENDENCIES, mais uniquement en développement. En production, ce ne sera pas du tout là. Cependant, lorsque vous utilisez (2), vous verrez "juillet" uniquement dans PATH, pas dans DEPENDENCIES, mais il apparaîtra lorsque vous êtes à bundle installpartir d'un environnement de production (c'est-à-dire dans un autre joyau qui inclut le vôtre en tant que dépendance), pas seul développement.

Ce ne sont que mes observations et je ne peux pas expliquer en détail pourquoi tout cela est ainsi, mais je suis heureux de recevoir d’autres commentaires.

Il semble qu'aucun document clair ne parle du Gemfile.lockformat. C'est peut-être parce qu'il Gemfile.lockest simplement utilisé par bundle en interne.

Cependant, puisque Gemfile.lockest un instantané de Gemfile, ce qui signifie que toutes ses informations doivent provenir Gemfile(ou de la valeur par défaut si elle n'est pas spécifiée dans Gemfile).

Pour GEM, il répertorie toutes les dépendances que vous introduisez directement ou indirectement dans le Gemfile. remoteunder GEMindique où obtenir les gemmes, qui est spécifié par la source dans Gemfile.

Si une gemme n'est pas récupérée remote, PATHindique l'emplacement pour la trouver. PATHLes informations de ce fichier proviennent de path in Gemfilelorsque vous déclarez une dépendance.

Et PLATFORMc'est d' ici .

Car DEPENDENCIES, c'est l'instantané des dépendances résolues par bundle.

Que signifie le point d'exclamation après le nom de la gemme dans le groupe «DÉPENDANCES»?

Le point d'exclamation apparaît lorsque le gem a été installé à l'aide d'une source autre que " https://rubygems.org ".