Uppdatering av ett beroende
Självklart kan det hända att du vid någon tidpunkt vill uppdatera versionen av ett visst beroende som din applikation är beroende av. Du kanske till exempel vill uppdaterarails till 3.0.0 final. Viktigt är att bara för att du uppdaterar ett beroende betyder det inte att du vill lösa upp alla dina beroenden på nytt och använda den senaste versionen av allt. I vårt exempel har du bara tre beroenden, men även i detta fall kan det orsaka komplikationer om du uppdaterar allt.
För att illustrera detta beror rails 3.0.0.rc gem på actionpack 3.0.0.rc gem, som beror på rack ~> 1.2.1 (vilket innebär att >= 1.2.1 och ). The rack-cache gem beror pårack >= 0.4. Låt oss anta att rails 3.0.0s slutliga gem också är beroende av rack ~> 1.2.1, och att sedan rails 3.0.0 släpptes har Rack-teamet släppt rack 1.2.2.
Om vi naivt uppdaterar alla våra gems för att uppdatera Rails får vi rack 1.2.2, som uppfyller kraven i både rails 3.0.0 och rack-cache. Vi bad dock inte specifikt om att uppdaterarack-cache, som kanske inte är kompatibel med rack 1.2.2 (oavsett anledning). Och även om en uppdatering från rack 1.2.1 till rack 1.2.2 förmodligen inte bryter mot något, kan liknande scenarier inträffa som innebär mycket större hopp. (se nedan för en större diskussion)
För att undvika detta problem kommer Bundler, när du uppdaterar en gem, inte att uppdatera ett beroende av den gemen om en annan gem fortfarande är beroende av den. I det här exemplet, eftersomrack-cache fortfarande är beroende av rack, kommer bundler inte att uppdaterarack-gemen. Detta säkerställer att uppdatering av rails inte oavsiktligt bryter ner rack-cache. Eftersom rails 3.0.0s beroendeactionpack 3.0.0 fortfarande är kompatibelt med rack 1.2.1, låter bundler det vara, och rack-cache fortsätter att fungera även om det är oförenligt med rack 1.2.2.
Då du ursprungligen deklarerade ett beroende av rails 3.0.0.rc, om du vill uppdatera till rails 3.0.0, uppdaterar du helt enkelt din Gemfile tillgem 'rails', '3.0.0' och kör:
$ bundle install Som beskrivet ovan gör kommandot bundle install alltid en konservativuppdatering, och vägrar att uppdatera pärlor (eller deras beroenden) som du inte uttryckligen har ändrat i Gemfile. Detta innebär att om du inte ändrarrack-cache i din Gemfile kommer bundler att behandla den **och dess beroenden** (rack) som en enda, icke-modifierbar enhet. Om rails 3.0.0 var inkompatibel med rack-cache kommer Bundler att rapportera en konflikt mellan dina snapshotted beroenden (Gemfile.lock) och din uppdaterade Gemfile.
Om du uppdaterar din Gemfile, och ditt system redan har alla nödvändiga beroenden, kommer Bundler att på ett transparent sätt uppdatera Gemfile.lock när du startar upp din applikation. Om du till exempel lägger till mysql till din Gemfile, och redan har installerat den i ditt system, kan du starta upp din applikation utan att köra bundle install, och bundler kommer att behålla den ”senast kända goda” konfigurationen till Gemfile.lock-snapshotet.
Detta kan vara praktiskt när du lägger till eller uppdaterar pärlor med minimala beroenden (databasedrivers, wirble, ruby-debug). Det kommer förmodligen att misslyckas om du uppdaterar gems med betydande beroenden (rails), eller som många gems är beroende av (rack). Om en transparent uppdatering misslyckas kommer din applikation att misslyckas med att starta, och Bundler kommer att skriva ut ett felmeddelande som instruerar dig att köra bundle install.