Updating a Dependency
Desigur, la un moment dat, s-ar putea să doriți să actualizați versiunea unei anumite dependențe pe care se bazează aplicația dumneavoastră. De exemplu, este posibil să doriți să actualizațirails la 3.0.0 final. Este important de reținut că, doar pentru că actualizați o dependență, nu înseamnă că doriți să rerezolvați toate dependențele și să folosiți cea mai recentă versiune a tuturor. În exemplul nostru, aveți doar treidependențe, dar chiar și în acest caz, actualizarea tuturor poate cauza complicații.
Pentru a ilustra, gemul rails 3.0.0.rc depinde de gemul actionpack 3.0.0.rc, care depinde de rack ~> 1.2.1 (ceea ce înseamnă că >= 1.2.1 și ). The rack-cache gemul depinde derack >= 0.4. Să presupunem că gemul final rails 3.0.0 depinde, de asemenea, de rack ~> 1.2.1 și că, de la lansarea lui rails 3.0.0, echipa Rack a lansat rack 1.2.2.
Dacă actualizăm naiv toate gemurile noastre pentru a actualiza Rails, vom obține rack 1.2.2, care satisface cerințele atât ale lui rails 3.0.0, cât și ale luirack-cache. Cu toate acestea, nu am cerut în mod specific să actualizămrack-cache, care ar putea să nu fie compatibil cu rack 1.2.2 (indiferent de motiv). Și în timp ce o actualizare de la rack 1.2.1 la rack 1.2.2 probabil că nu va strica nimic, se pot întâmpla scenarii similare care implică salturi mult mai mari. (a se vedea mai jos pentru o discuție mai amplă)
Pentru a evita această problemă, atunci când actualizați o gemă, bundler nu va actualiza o dependență a acelei gemă dacă o altă gemă depinde încă de ea. În acest exemplu, deoarecerack-cache depinde încă de rack, bundler nu va actualiza gemulrack. Acest lucru asigură faptul că actualizarea rails nu strică din greșeală rack-cache. Deoarece dependența rails 3.0.0 de actionpack 3.0.0 rămâne compatibilă cu rack 1.2.1, bundler o lasă în pace, iar rack-cache continuă să funcționeze chiar și în fața unei incompatibilități cu rack 1.2.2.
Din moment ce ați declarat inițial o dependență de rails 3.0.0.rc, dacă doriți să actualizați la rails 3.0.0, pur și simplu actualizați Gemfile lagem 'rails', '3.0.0' și rulați:
$ bundle install După cum a fost descris mai sus, comanda bundle install face întotdeauna o actualizare conservatoare, refuzând să actualizeze gemele (sau dependențele lor) pe care nu le-ați modificat în mod explicit în Gemfile. Aceasta înseamnă că, dacă nu modificațirack-cache în Gemfile, bundler o va trata **și dependențele sale** (rack) ca pe o singură unitate nemodificabilă. Dacă rails 3.0.0 a fost incompatibil cu rack-cache, bundler va raporta unconflict între dependențele dvs. instantanee (Gemfile.lock) și Gemfile actualizat.
Dacă vă actualizați Gemfile, iar sistemul dvs. are deja toate dependențele necesare, bundler va actualiza transparent Gemfile.lock atunci când vă porniți aplicația. De exemplu, dacă adăugați mysql la Gemfile și l-ați instalat deja în sistem, puteți să vă porniți aplicația fără să rulați bundle install, iar bundler va persista „ultima configurație bună cunoscută” în instantaneul Gemfile.lock.
Acest lucru poate fi util atunci când adăugați sau actualizați gemuri cu dependențe minime (databasedrivers, wirble, ruby-debug). Probabil că va eșua dacăactualizați pietre prețioase cu dependențe semnificative (rails) sau de care depind o mulțime de pietre prețioase (rack). Dacă o actualizare transparentă eșuează, aplicația dvs. nu va reuși să pornească, iar bundler va tipări o eroare care vă va instrui să rulați bundle install.
.