Aktualisieren einer Abhängigkeit
Natürlich kann es vorkommen, dass man die Version einer bestimmten Abhängigkeit, auf die sich die Anwendung verlässt, aktualisieren möchte. Zum Beispiel könnten Sie rails auf 3.0.0 final aktualisieren wollen. Nur weil Sie eine Abhängigkeit aktualisieren, bedeutet das nicht, dass Sie alle Ihre Abhängigkeiten neu auflösen und die neueste Version von allem verwenden wollen. In unserem Beispiel gibt es nur drei Abhängigkeiten, aber selbst in diesem Fall kann die Aktualisierung aller Abhängigkeiten zu Komplikationen führen.
Zur Veranschaulichung: der rails 3.0.0.rc gem hängt von actionpack 3.0.0.rc gem ab, der wiederum von rack ~> 1.2.1 abhängt (was bedeutet, dass >= 1.2.1 und ). The rack-cache gem vonrack >= 0.4 abhängen. Nehmen wir an, dass das finale Gem rails 3.0.0 ebenfalls von rack ~> 1.2.1 abhängt und dass das Rack-Team seit der Veröffentlichung von rails 3.0.0 rack 1.2.2 veröffentlicht hat.
Wenn wir naiverweise alle unsere Gems aktualisieren, um Rails zu aktualisieren, erhalten wir rack 1.2.2, das die Anforderungen von rails 3.0.0 und rack-cache erfüllt. Wir haben jedoch nicht ausdrücklich darum gebeten, rack-cache zu aktualisieren, das möglicherweise nicht mit rack 1.2.2 kompatibel ist (aus welchen Gründen auch immer). Und während eine Aktualisierung von rack 1.2.1 auf rack 1.2.2 wahrscheinlich nichts kaputt macht, können ähnliche Szenarien auftreten, die viel größere Sprünge beinhalten. (siehe unten für eine ausführlichere Diskussion)
Um dieses Problem zu vermeiden, wird Bundler bei der Aktualisierung eines Edelsteins dessen Abhängigkeit nicht aktualisieren, wenn ein anderer Edelstein noch davon abhängt. Da in diesem Beispielrack-cache immer noch von rack abhängt, wird Bundler den Edelstein rack nicht aktualisieren. Dadurch wird sichergestellt, dass die Aktualisierung von rails nicht versehentlich rack-cache beschädigt. Da die Abhängigkeit von rails 3.0.0 von actionpack 3.0.0 mit rack 1.2.1 kompatibel bleibt, lässt Bundler sie in Ruhe, und rack-cache funktioniert weiterhin, auch wenn eine Inkompatibilität mit rack 1.2.2 besteht.
Da Sie ursprünglich eine Abhängigkeit von rails 3.0.0.rc deklariert haben, aktualisieren Sie, wenn Sie auf rails 3.0.0 aktualisieren wollen, einfach Ihre Gemfile aufgem 'rails', '3.0.0' und führen Sie aus:
$ bundle install Wie oben beschrieben, führt der Befehl bundle install immer ein konservatives Update durch und weigert sich, Edelsteine (oder deren Abhängigkeiten) zu aktualisieren, die Sie nicht explizit in der Gemfile geändert haben. Das bedeutet, dass, wenn Sie rack-cache in Ihrer Gemfile nicht ändern, Bundler es **und seine Abhängigkeiten** (rack) als eine einzige, nicht änderbare Einheit behandelt. Wenn rails 3.0.0 mit rack-cache inkompatibel war, meldet Bundler einen Konflikt zwischen Ihren Snapshot-Abhängigkeiten (Gemfile.lock) und Ihrer aktualisierten Gemfile.
Wenn Sie Ihre Gemfile aktualisieren und Ihr System bereits über alle benötigten Abhängigkeiten verfügt, aktualisiert Bundler die Gemfile.lock transparent, wenn Sie Ihre Anwendung starten. Wenn Sie zum Beispiel mysql zu Ihrem Gemfile hinzufügen und es bereits in Ihrem System installiert haben, können Sie Ihre Anwendung starten, ohne bundle install auszuführen, und Bundler wird die „letzte als gut bekannte“ Konfiguration im Gemfile.lock-Snapshot beibehalten.
Dies kann nützlich sein, wenn Sie Edelsteine mit minimalen Abhängigkeiten hinzufügen oder aktualisieren (datenbankbasierte Treiber, wirble, ruby-debug). Es wird wahrscheinlich fehlschlagen, wenn Sie Gems mit signifikanten Abhängigkeiten aktualisieren (rails), oder von denen viele Gems abhängig sind (rack). Wenn ein transparentes Update fehlschlägt, wird Ihre Anwendung nicht starten und Bundler wird eine Fehlermeldung ausgeben, die Sie anweist, bundle install.
auszuführen.