Réponses:
C'est Gemfile
là que vous spécifiez les gemmes que vous souhaitez utiliser et vous permet de spécifier les versions.
Le Gemfile.lock
fichier est l'endroit où Bundler enregistre les versions exactes qui ont été installées. De cette façon, lorsque la même bibliothèque / projet est chargé sur une autre machine, l'exécution bundle install
examinera Gemfile.lock
et installera exactement les mêmes versions, plutôt que d'utiliser simplement Gemfile
et d'installer les versions les plus récentes. (L'exécution de différentes versions sur différentes machines peut entraîner des tests défectueux, etc.) Vous ne devriez jamais avoir à modifier directement le fichier de verrouillage.
Consultez l'objectif et la justification de Bundler , en particulier la section Vérification de votre code dans le contrôle de version.
Habituellement, nous écrivons les dépendances dans Gemfile comme suit:
gem "nokogiri", "~> 1.4.4"
gem 'bcrypt-ruby', '~> 3.0.0'
gem 'uglifier', '>= 1.2.3'
..
Ici, vous dites essentiellement: " Je veux nokogiri tant qu'il est supérieur à la version 1.4.4 ", etc. Supposons maintenant que j'ai configuré mon Gemfile
il y a 8 mois et que j'ai réussi à configurer mon application avec cette exigence. Il y a 8 mois, la version nokogiri était la 1.4.4 . Mes applications de rails fonctionnaient parfaitement sans aucun problème avec cette version.
Maintenant pense que j'essaye de construire avec le même Gemfile
. Mais si nous regardons les versions de nokogiri, nous voyons que la version stable actuelle a changé en 1.4.9 . Cela signifie que si nous essayons de construire, le bundler installera la version 1.4.9 de nokogiri (supposons que nous ne l'ayons pas Gemfile.lock
).
Comme vous voyez si vous n'en avez pas Gemfile.lock
et exécutez:
bundle install
alors les gemmes actuellement utilisées peuvent être différentes à tout moment . Votre application a utilisé la version 1.4.4 et elle fonctionne il y a 8 mois sans aucun problème, mais si vous essayez de la construire maintenant, vous obtenez la version 1.4.9 . Peut-être que c'est cassé avec la dernière version de nokogiri
, la fonctionnalité géniale que vous avez utilisée avec la 1.4.4 n'est plus disponible, etc.
Pour éviter ce genre de problème Gemfile.lock
est utilisé. Dans Gemfile.lock
seules les versions exactes sont écrites et donc que ceux - ci seront installés. Cela signifie que si vous distribuez votre application avec un Gemfile.lock
, chaque machine aura les mêmes gemmes installées et le plus important, elles auront toutes la même version . Cela vous donnera une pile de déploiement stable et commune.
Il est automatiquement créé avec le premier:
bundle install
commander. Après cela, à chaque fois que vous exécutez bundle install
, le bundle recherchera Gemfile.lock
et installera d'abord les gemmes spécifiées ici. C'est une habitude de distribuer ce fichier parmi vos projets pour assurer cohérence et stabilité.
Si vous êtes satisfait de la dernière version de vos applications, vous pouvez la mettre à jour Gemfile.lock
. Reflétez simplement vos changements dans Gemfile
. Cela signifie changer les dépendances avec les nouvelles versions exactes dans Gemfile
. Après cette course:
bundle install
Cela vous mettra à jour Gemfile.lock
avec votre dernière version des applications.
nokogiri ~> 1.4.4
ne permettrait pas 1.5.3
d'être installé; max autorisé serait 1.4.x
où x>=4
(pour nokogiri ce serait 1.4.7
). L' ~>
opérateur signifie que seul le dernier chiffre de la gemme utilisée peut être "supérieur" à la version donnée. Par exemple, cela foo ~> a.b.c.d
signifie que toute version de foo
est bien tant qu'elle est toujours abc {quelque chose} où {quelque chose} >=
d. Voir aussi la question connexe
gem "nokogiri", "~> 1.4.4"
dans le gemfile. Pourquoi le bundler ne pouvait-il pas simplement utiliser cette version? Est-ce parce qu'il est conçu pour installer intentionnellement les dernières versions du gem par défaut?
~> 1.4.4
équivaut à >= 1.4.4 and < 1.5
. Voir bundler.io/v1.5/gemfile.html . Pour une version exacte, utilisez simplement gem 'foo', '1.4.4'
.
bundle install
t-elle que vérifiera le Gemfile
même s'il y a un Gemfile.lock
et appliquera de nouvelles restrictions Gemfile.lock
?
Le Gemfile.lock
Lorsque vous exécutez l'installation de bundle, Bundler conservera les noms complets et les versions de toutes les gemmes que vous avez utilisées (y compris les dépendances des gemmes spécifiées dans Gemfile (5)) dans un fichier appelé Gemfile.lock.
Bundler utilise ce fichier dans tous les appels ultérieurs à l'installation de bundle, ce qui garantit que vous utilisez toujours le même code exact, même lorsque votre application se déplace entre les machines.
En raison du fonctionnement de la résolution des dépendances, même un changement en apparence minime (par exemple, une mise à jour d'une version provisoire d'une dépendance d'une gemme dans votre Gemfile (5)) peut entraîner la nécessité de gemmes radicalement différentes pour satisfaire toutes les dépendances.
En conséquence, vous DEVRIEZ vérifier votre Gemfile.lock dans le contrôle de version. Si vous ne le faites pas, chaque machine qui extrait votre référentiel (y compris votre serveur de production) résoudra à nouveau toutes les dépendances, ce qui entraînera l'utilisation de différentes versions de code tiers si l'une des gemmes du Gemfile (5) ou tout autre de leurs dépendances ont été mises à jour.
Gemfile.lock
versions "ouvertes" incluent dans certains cas (par exemple,rails (4.0.0)
nécessitebundler (>= 1.3.0, < 2.0)
), ce qui pose des problèmes. Une idée comment éviter ces dépendances «ouvertes»?