Mise à jour d’une dépendance
Bien sûr, à un moment donné, vous pourriez vouloir mettre à jour la version d’une dépendance particulaire sur laquelle votre application repose. Par exemple, vous pourriez vouloir mettre à jourrails en 3.0.0 final. Il est important de noter que ce n’est pas parce que vous mettez à jour une dépendance que vous devez résoudre à nouveau toutes vos dépendances et utiliser la dernière version de toutes les dépendances. Dans notre exemple, vous n’avez que trois dépendances, mais même dans ce cas, tout mettre à jour peut entraîner des complications.
Pour illustrer, la gem rails 3.0.0.rc dépend de la gem actionpack 3.0.0.rc, qui dépend de rack ~> 1.2.1 (ce qui signifie >= 1.2.1 et ). The rack-cache gem dépend derack >= 0.4. Supposons que la gemme finale rails 3.0.0 dépende également de rack ~> 1.2.1, et que depuis la publication de rails 3.0.0, l'équipe Rack a publié rack 1.2.2.
Si nous mettons naïvement à jour toutes nos gemmes afin de mettre à jour Rails, nous obtiendrons rack 1.2.2, qui satisfait aux exigences de rails 3.0.0 etrack-cache. Cependant, nous n’avons pas demandé spécifiquement de mettre à jourrack-cache, qui peut ne pas être compatible avec rack 1.2.2 (pour quelque raison que ce soit). Et si une mise à jour de rack 1.2.1 à rack 1.2.2 ne cassera probablement rien, des scénarios similaires peuvent se produire qui impliquent des sauts beaucoup plus importants. (voir ci-dessous pour une discussion plus large)
Afin d’éviter ce problème, lorsque vous mettez à jour une gemme, bundler ne mettra pas à jour une dépendance de cette gemme si une autre gemme en dépend encore. Dans cet exemple, puisquerack-cache dépend toujours de rack, bundler ne mettra pas à jour la gemmerack. Cela garantit que la mise à jour de rails ne casse pas rack-cache par inadvertance. Puisque la dépendanceactionpack 3.0.0 de rails 3.0.0 reste compatible avec rack 1.2.1, bundler la laisse tranquille, et rack-cache continue de fonctionner même face à une incompatibilité avec rack 1.2.2.
Puisque vous avez initialement déclaré une dépendance à rails 3.0.0.rc, si vous voulez mettre à jour vers rails 3.0.0, mettez simplement à jour votre Gemfile versgem 'rails', '3.0.0' et exécutez :
$ bundle install Comme décrit ci-dessus, la commande bundle install fait toujours une mise à jour conservatrice, refusant de mettre à jour les gemmes (ou leurs dépendances) que vous n’avez pas explicitementchangé dans le Gemfile. Cela signifie que si vous ne modifiez pasrack-cache dans votre Gemfile, bundler le traitera **et sesdépendances** (rack) comme une seule unité non modifiable. Si rails 3.0.0 était incompatible avec rack-cache, bundler signalera un conflit entre vos dépendances snapshotées (Gemfile.lock) et votre Gemfile mis à jour.
Si vous mettez à jour votre Gemfile, et que votre système possède déjà toutes les dépendances nécessaires, bundler mettra à jour de manière transparente le Gemfile.lock lorsque vous démarrerez votre application. Par exemple, si vous ajoutez mysql à votreGemfile, et que vous l’avez déjà installé dans votre système, vous pouvez démarrer votreapplication sans exécuter bundle install, et bundler persistera la « dernière bonne configuration connue » dans le snapshot Gemfile.lock.
Cela peut s’avérer pratique lors de l’ajout ou de la mise à jour de gemmes avec des dépendances minimales (databasedrivers, wirble, ruby-debug). Il échouera probablement si vousmettez à jour des gemmes avec des dépendances importantes (rails), ou dont beaucoup de gems dépendent (rack). Si une mise à jour transparente échoue, votre application ne démarrera pas, et bundler affichera une erreur vous indiquant d’exécuter bundle install.
.