Bundler: Hoe edelstenen bijwerken met Bundler

Een afhankelijkheid bijwerken

Op een bepaald moment kan het natuurlijk zijn dat u de versie van een bepaalde afhankelijkheid waarvan uw toepassing afhankelijk is, wilt bijwerken. Bijvoorbeeld, u zourails kunnen willen updaten naar 3.0.0 final. Belangrijk is dat, alleen omdat je één dependency update, het niet betekent dat je al je dependencies opnieuw moet oplossen en de laatste versie van alles moet gebruiken. In ons voorbeeld heeft u slechts drie afhankelijkheden, maar zelfs in dit geval kan het bijwerken van alles complicaties veroorzaken.

Om te illustreren, de rails 3.0.0.rc gem hangt af van actionpack 3.0.0.rc gem, die afhangt van rack ~> 1.2.1 (wat betekent dat >= 1.2.1 en ). The rack-cache gem afhangt vanrack >= 0.4. Laten we aannemen dat de rails 3.0.0 final gem ook afhankelijk is van rack ~> 1.2.1, en dat sinds de release van rails 3.0.0, het Rack team rack 1.2.2 heeft uitgebracht.

Als we naïef al onze gems updaten om Rails te updaten, krijgen we rack 1.2.2, die voldoet aan de vereisten van zowel rails 3.0.0 alsrack-cache. We hebben echter niet specifiek gevraagd omrack-cache bij te werken, die misschien niet compatibel is met rack 1.2.2 (om welke reden dan ook). En terwijl een update van rack 1.2.1 naar rack 1.2.2 waarschijnlijk niets zal breken, kunnen soortgelijke scenario’s zich voordoen die veel grotere sprongen impliceren. (zie hieronder voor een grotere discussie)

Om dit probleem te voorkomen, wanneer je een gem update, zal bundler niet een afhankelijkheid van die gem updaten als een andere gem er nog steeds van afhangt. In dit voorbeeld, omdatrack-cache nog steeds afhankelijk is van rack, zal bundler derack gem niet bijwerken. Dit zorgt ervoor dat het bijwerken van rails niet per ongeluk rack-cache breekt. Omdat rails 3.0.0’s afhankelijkheidactionpack 3.0.0 compatibel blijft met rack 1.2.1, laat bundler het met rust, en rack-cache blijft werken, zelfs in het gezicht van een incompatibiliteit met rack 1.2.2.

Omdat u oorspronkelijk een afhankelijkheid van rails 3.0.0.rc heeft aangegeven, als u wilt updaten naar rails 3.0.0, hoeft u alleen maar uw Gemfile bij te werken naargem 'rails', '3.0.0' en uit te voeren:

$ bundle install 

Zoals hierboven beschreven, voert het bundle install commando altijd een conservatieve update uit, waarbij gems (of hun afhankelijkheden) die u niet expliciet in de Gemfile heeft veranderd, niet worden bijgewerkt. Dit betekent dat als urack-cache niet wijzigt in uw Gemfile, bundler het **en zijn afhankelijkheden** (rack) zal behandelen als een enkele, niet wijzigbare eenheid. Als rails 3.0.0 incompatibel was met rack-cache, zal bundler een conflict rapporteren tussen uw snapshotted afhankelijkheden (Gemfile.lock) en uw geupdate Gemfile.

Als u uw Gemfile update, en uw systeem heeft al de benodigde afhankelijkheden, zal bundler transparant de Gemfile.lock updaten wanneer u uw applicatie opstart. Bijvoorbeeld, als u mysql aan uwGemfile toevoegt, en het al in uw systeem hebt geinstalleerd, kunt u uw applicatie starten zonder bundle install te draaien, en bundler zal de “laatst bekende goede” configuratie in de Gemfile.lock snapshot houden.

Dit kan van pas komen bij het toevoegen of updaten van edelstenen met minimale afhankelijkheden (databasedrivers, wirble, ruby-debug). Het zal waarschijnlijk mislukken als u gems bijwerkt met aanzienlijke afhankelijkheden (rails), of waar veel gems van afhankelijk zijn (rack). Als een transparante update mislukt, zal uw applicatie niet opstarten, en bundler zal een fout uitprinten met de instructie om bundle install.

uit te voeren

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.