bundle-install - Installieren Sie die in Ihrer Gemfile angegebenen Abhängigkeiten
bundle install [--binstubs[=DIRECTORY]] [--clean] [--deployment] [--frozen] [--full-index] [--gemfile=GEMFILE] [--jobs=NUMBER] [--local] [--no-cache] [--no-prune] [--path PATH] [--quiet] [--redownload] [--retry=NUMBER] [--shebang] [--standalone[=GROUP[ GROUP...]]] [--system] [--trust-policy=POLICY] [--with=GROUP[ GROUP...]] [--without=GROUP[ GROUP...]]
Installieren Sie die in Ihrer Gemfile(5) angegebenen Gems. Wenn Sie die Bundle-Installation zum ersten Mal ausführen (und kein Gemfile.lock vorhanden ist), ruft Bundler alle Remote-Quellen ab, löst Abhängigkeiten auf und installiert alle benötigten Gems.
Wenn ein Gemfile.lock vorhanden ist und Sie Ihr Gemfile(5) nicht aktualisiert haben, ruft Bundler alle Remote-Quellen ab, verwendet jedoch die im Gemfile.lock angegebenen Abhängigkeiten statt Abhängigkeiten aufzulösen.
Wenn ein Gemfile.lock vorhanden ist und Sie Ihr Gemfile(5) aktualisiert haben, verwendet Bundler die Abhängigkeiten im Gemfile.lock für alle Gems, die Sie nicht aktualisiert haben , löst aber die Abhängigkeiten der Gems, die Sie aktualisiert haben, erneut auf. Weitere Informationen zu diesem Aktualisierungsprozess finden Sie weiter unten unter KONSERVATIVE AKTUALISIERUNG.
Die --clean, --deployment, --frozen, --no-prune, --path, --shebang, --system, --without und --with Optionen sind veraltet, da sie nur dann Sinn machen, wenn sie bei jeder nachfolgenden Bundle-Installation automatisch angewendet werden und das erfordert, dass sich Bundler sie stillschweigend merkt. Da Bundler sich CLI-Flags in zukünftigen Versionen nicht mehr merken wird, sollte Bundle config (siehe bundle-config(1)) verwendet werden, um sie dauerhaft anzuwenden.
Binstubs sind Skripte, die ausführbare Dateien umschließen. Bundler erstellt eine kleine Ruby-Datei (einen Binstub), der Bundler lädt, den Befehl ausführt und ihn in bin/ ablegt. Dadurch können Sie den Binstub innerhalb einer Anwendung mit der genauen Gem-Version verknüpfen, die die Anwendung benötigt.
Erstellt ein Verzeichnis (standardmäßig ~/bin) und platziert dort alle ausführbaren Dateien aus dem Gem. Diese ausführbaren Dateien werden im Bundler-Kontext ausgeführt. Bei Verwendung können Sie dieses Verzeichnis zur Variablen PATH Ihrer Umgebung hinzufügen. Wenn das Rails-Gem beispielsweise mit einer ausführbaren Rails-Datei geliefert wird, erstellt dieses Flag eine ausführbare bin/rails-Datei, die sicherstellt, dass alle referenzierten Abhängigkeiten dies tun kann mithilfe der gebündelten Edelsteine gelöst werden.
Nach Abschluss der Installation entfernt Bundler alle Gems, die nicht in der aktuellen Gemfile(5) vorhanden sind. Keine Sorge, derzeit verwendete Edelsteine werden nicht entfernt.
Diese Option ist zugunsten der Einstellung sauber veraltet.
Im Bereitstellungsmodus „rollt“ Bundler das Bundle für die Produktion oder CI-Nutzung aus. Bitte prüfen Sie sorgfältig, ob Sie diese Option in Ihrer Entwicklungsumgebung aktiviert haben möchten.
Diese Option ist zugunsten der Einstellung Bereitstellung veraltet.
Erzwingen Sie den Download jedes Gems, auch wenn die erforderlichen Versionen bereits lokal verfügbar sind.
Lassen Sie nicht zu, dass Gemfile.lock nach dieser Installation aktualisiert wird. Wird ungleich Null beendet, wenn Änderungen an Gemfile.lock vorgenommen werden.
Diese Option ist zugunsten der Einstellung eingefroren veraltet.
Bundler ruft nicht den API-Endpunkt von Rubygems auf (Standard), sondern lädt eine (derzeit große) Indexdatei aller Gems herunter und speichert sie zwischen. Durch Aktivieren dieser Option kann die Leistung bei großen Bundles, die sich selten ändern, verbessert werden.
Der Speicherort der Gemfile(5), den Bundler verwenden soll. Dies ist standardmäßig eine Gemfile(5) im aktuellen Arbeitsverzeichnis. Im Allgemeinen geht Bundler davon aus, dass der Speicherort der Gemfile(5) auch das Stammverzeichnis des Projekts ist, und versucht, Gemfile.lock und vendor/cache relativ zu diesem Speicherort zu finden .
Die maximale Anzahl paralleler Download- und Installationsjobs. Der Standardwert ist die Anzahl der verfügbaren Prozessoren.
Versuchen Sie nicht, eine Verbindung zu rubygems.org herzustellen. Stattdessen verwendet Bundler die Edelsteine, die bereits im Cache von Rubygems oder im Vendor/Cache vorhanden sind. Beachten Sie, dass ein geeignetes plattformspezifisches Gem nicht gefunden wird, wenn es auf rubygems.org vorhanden ist.
Erzwingen Sie beim Auflösen die Verwendung lokal installierter Gems oder bereits im Cache von Rubygems oder im Anbieter/Cache vorhandener Gems, auch wenn neuere Versionen remote verfügbar sind. Versuchen Sie nur, eine Verbindung zu rubygems.org für Edelsteine herzustellen, die nicht lokal vorhanden sind.
Aktualisieren Sie den Cache in vendor/cache nicht mit den neu gebündelten Gems. Dadurch werden keine Gems im Cache entfernt, es wird jedoch verhindert, dass die neu gebündelten Gems während der Installation zwischengespeichert werden.
Entfernen Sie veraltete Gems nicht aus dem Cache, wenn die Installation abgeschlossen ist.
Diese Option ist zugunsten der Einstellung no_prune veraltet.
Der Speicherort, an dem die angegebenen Gems installiert werden sollen. Dies ist standardmäßig die Einstellung von Rubygems. Bundler teilt diesen Speicherort mit Rubygems, gem install ... wird gem auch dort installiert haben. Daher werden Gems, die ohne die Einstellung --path ... installiert wurden, durch den Aufruf von gem list angezeigt. Dementsprechend werden an anderen Orten installierte Edelsteine nicht aufgelistet.
Diese Option ist zugunsten der Einstellung Pfad veraltet.
Drucken Sie keine Fortschrittsinformationen auf der Standardausgabe. Stattdessen wird Bundler mit einem Statuscode ($?) beendet.
Wiederholen Sie fehlgeschlagene Netzwerk- oder Git-Anfragen so oft Mal.
Verwendet die angegebene ausführbare Ruby-Datei (normalerweise Ruby), um die mit --binstubs erstellten Skripte auszuführen. Wenn Sie außerdem --binstubs zusammen mit --shebang jruby verwenden, werden diese ausführbaren Dateien so geändert, dass stattdessen jruby ausgeführt wird.
Diese Option ist zugunsten der Einstellung shebang veraltet.
Erstellt ein Bundle, das zur Laufzeit ohne Abhängigkeit von Rubygems oder Bundler funktionieren kann. Es muss eine durch Leerzeichen getrennte Liste der zu installierenden Gruppen angegeben werden. Bundler erstellt ein Verzeichnis mit dem Namen bundle und installiert das Bundle dort. Außerdem wird eine Datei bundle/bundler/setup.rb generiert, um Bundlers eigenes Setup auf die erforderliche Weise zu ersetzen. Durch die Verwendung dieser Option wird implizit der Pfad festgelegt, bei dem es sich um eine [erinnerte Option][ERINNERTE OPTIONEN] handelt.
Installiert die im Bundle angegebenen Gems am Rubygems-Speicherort des Systems. Dies überschreibt alle vorherigen Konfigurationen von --path.
Diese Option ist zugunsten der System-Einstellung veraltet.
Wenden Sie die Rubygems-Sicherheitsrichtlinie policy an, wobei die Richtlinie eine von HighSecurity, MediumSecurity, LowSecurity, AlmostNoSecurity) ist oder NoSecurity. Weitere Einzelheiten finden Sie in der unten verlinkten Rubygems-Signaturdokumentation unter SIEHE AUCH.
Eine durch Leerzeichen getrennte Liste von Gruppen, die auf zu installierende Gems verweisen. Wenn eine optionale Gruppe angegeben ist, wird diese installiert. Wenn eine Gruppe angegeben wird, die sich in der gespeicherten Liste der an --without übergebenen Gruppen befindet, wird sie aus dieser Liste entfernt.
Diese Option ist zugunsten der Einstellung with veraltet.
Eine durch Leerzeichen getrennte Liste von Gruppen, die auf Gems verweisen, die während der Installation übersprungen werden sollen. Wenn eine Gruppe angegeben wird, die sich in der gespeicherten Liste der an --with übergebenen Gruppen befindet, wird sie aus dieser Liste entfernt.
Diese Option ist zugunsten der Einstellung ohne veraltet.
Die Standardeinstellungen von Bundler sind für die Entwicklung optimiert. Um zu für die Bereitstellung und CI optimierten Standardeinstellungen zu wechseln, verwenden Sie das Flag --deployment. Aktivieren Sie den Bereitstellungsmodus nicht auf Entwicklungsmaschinen, da dies zu einem Fehler führt, wenn die Gemfile(5) geändert wird.
Ein Gemfile.lock ist erforderlich. Um sicherzustellen, dass dieselben Versionen der Gems, mit denen Sie entwickelt und getestet haben, auch in Bereitstellungen verwendet werden, ist eine Gemfile.lock erforderlich. Dies dient hauptsächlich dazu, sicherzustellen, dass Sie daran denken, Ihre Gemfile.lock in die Versionskontrolle einzuchecken.
Die Gemfile.lock muss aktuell sein In der Entwicklung können Sie Ihr Gemfile(5) ändern und Bundle Install erneut ausführen, um Ihren Gemfile.lock-Snapshot konservativ zu aktualisieren. Bei der Bereitstellung sollte Ihr Gemfile.lock mit den in Ihrem Gemfile(5) vorgenommenen Änderungen auf dem neuesten Stand sein.
Gems werden unter Anbieter/Bundle installiert, nicht an Ihrem Standardsystemstandort In der Entwicklung ist es praktisch, die in Ihrer Anwendung verwendeten Gems mit anderen Anwendungen und anderen Skripten zu teilen, die auf dem System ausgeführt werden. Bei der Bereitstellung ist Isolation ein wichtigerer Standard. Darüber hinaus verfügt der Benutzer, der die Anwendung bereitstellt, möglicherweise nicht über die Berechtigung, Gems auf dem System zu installieren, oder der Webserver verfügt möglicherweise nicht über die Berechtigung, sie zu lesen. Infolgedessen installiert bundle install --deployment Gems im Verzeichnis vendor/bundle in der Anwendung. Dies kann mit der Option --path überschrieben werden.
Standardmäßig installiert Bundle Install alle Gems in allen Gruppen in Ihrer Gemfile(5), mit Ausnahme derjenigen, die für eine andere Plattform deklariert sind.
Sie können Bundler jedoch explizit anweisen, die Installation bestimmter Gruppen mit der Option --without zu überspringen. Diese Option akzeptiert eine durch Leerzeichen getrennte Liste von Gruppen.
Während die Option --without die Installation der Gems in den angegebenen Gruppen überspringt, werden diese Gems dennoch heruntergeladen und zum Auflösen der Abhängigkeiten verwendet jedes Edelsteins in Ihrer Gemfile(5).
Dadurch wird sichergestellt, dass durch die Installation eines anderen Gruppensatzes auf einem anderen Computer (z. B. einem Produktionsserver) die Gems und Versionen, die Sie bereits entwickelt und getestet haben, nicht geändert werden.
Bundler bietet eine felsenfeste Garantie dafür, dass der Code von Drittanbietern, den Sie in der Entwicklung und beim Testen ausführen, auch der Code von Drittanbietern ist, den Sie in der Produktion ausführen. Sie können sich dafür entscheiden, einen Teil dieses Codes in verschiedenen Umgebungen auszuschließen, aber Sie werden nie auf dem falschen Fuß erwischt, wenn unterschiedliche Versionen von Code von Drittanbietern in verschiedenen Umgebungen verwendet werden.
Betrachten Sie zur einfachen Veranschaulichung die folgende Gemfile(5):
source 'https://rubygems.org'
gem 'sinatra'
group :production do
gem 'rack-perftools-profiler'
endIn diesem Fall hängt sinatra von jeder Rack-Version ab (>= 1.0), während rack-perftools-profiler von 1.x abhängt ( ~> 1.0).
Wenn Sie bundle install --without Production in der Entwicklung ausführen, betrachten wir auch die Abhängigkeiten von rack-perftools-profiler. Auf diese Weise verbringen Sie nicht Ihre ganze Zeit damit, gegen Rack 2.0 zu entwickeln und neue APIs zu verwenden, die in Rack 1.x nicht verfügbar sind, nur um Bundler zu Rack 1.2 wechseln zu lassen, wenn die Produktion-Gruppe ist verwendet.
Dies sollte in der Praxis keine Probleme verursachen, da wir nicht versuchen, die Gems in den ausgeschlossenen Gruppen zu installieren, sondern nur im Rahmen des Abhängigkeitsauflösungsprozesses auswerten.
Dies bedeutet auch, dass Sie nicht verschiedene Versionen desselben Gems in verschiedene Gruppen aufnehmen können, da dies zu unterschiedlichen Abhängigkeiten führen würde, die in der Entwicklung und Produktion verwendet werden. Aufgrund der Launen des Abhängigkeitsauflösungsprozesses betrifft dies normalerweise mehr als die Gems, die Sie in Ihrer Gemfile(5) auflisten, und kann (überraschenderweise) die von Ihnen verwendeten Gems radikal verändern.
Wenn Sie bundle install ausführen, speichert Bundler die vollständigen Namen und Versionen aller von Ihnen verwendeten Gems (einschließlich Abhängigkeiten der in Gemfile(5) angegebenen Gems) in einer Datei namens Gemfile. sperren.
Bundler verwendet diese Datei in allen nachfolgenden Aufrufen von bundle install, was garantiert, dass Sie immer genau denselben Code verwenden, auch wenn Ihre Anwendung auf mehrere Computer verschoben wird.
Aufgrund der Art und Weise, wie die Abhängigkeitsauflösung funktioniert, kann selbst eine scheinbar kleine Änderung (z. B. ein Update auf ein Point-Release einer Abhängigkeit eines Gems in Ihrer Gemfile(5)) dazu führen, dass völlig unterschiedliche Gems erforderlich sind, um alle Abhängigkeiten zu erfüllen.
Aus diesem Grund SOLLTEN Sie Ihre Gemfile.lock in die Versionskontrolle einchecken, sowohl in Anwendungen als auch in Gems. Wenn Sie dies nicht tun, löst jeder Computer, der Ihr Repository auscheckt (einschließlich Ihres Produktionsservers), alle Abhängigkeiten erneut auf, was dazu führt, dass unterschiedliche Versionen von Code von Drittanbietern verwendet werden, wenn irgendeine Gems darin enthalten sind Die Gemfile(5) oder eine ihrer Abhängigkeiten wurde aktualisiert.
Als Bundler zum ersten Mal ausgeliefert wurde, war Gemfile.lock in der .gitignore-Datei enthalten, die in den generierten Gems enthalten war. Im Laufe der Zeit wurde jedoch klar, dass diese Praxis den Schmerz gebrochener Abhängigkeiten neuen Mitwirkenden aufbürdet, während bestehende Mitwirkende sich des Problems möglicherweise nicht bewusst sind. Da die Bundle-Installation normalerweise der erste Schritt zu einem Beitrag ist, würde der Schmerz unterbrochener Abhängigkeiten neue Mitwirkende davon abhalten, einen Beitrag zu leisten. Aus diesem Grund haben wir unsere Anleitung für Edelsteinautoren überarbeitet und empfehlen nun, das Schloss auf Edelsteine zu überprüfen.
Wenn Sie eine Änderung an der Gemfile(5) vornehmen und dann Bundle Install ausführen, aktualisiert Bundler nur die Gems, die Sie geändert haben.
Mit anderen Worten: Wenn ein Gem, das Sie nicht geändert haben, funktionierte, bevor Sie Bundle Install aufgerufen haben, verwendet es weiterhin genau dieselben Versionen aller Abhängigkeiten wie vor dem aktualisieren.
Schauen wir uns ein Beispiel an. Hier ist Ihre ursprüngliche Gemfile(5):
source 'https://rubygems.org'
gem 'actionpack', '2.3.8'
gem 'activemerchant'In diesem Fall sind sowohl actionpack als auch activemerchant auf activesupport angewiesen. Das Actionpack-Gem hängt von activesupport 2.3.8 und rack ~> 1.1.0 ab, während das activemerchant-Gem davon abhängt auf activesupport >= 2.3.2, braintree >= 2.0.0 und builder >= 2.0.0.
Wenn die Abhängigkeiten zum ersten Mal aufgelöst werden, wählt Bundler activesupport 2.3.8 aus, das die Anforderungen beider Gems in Ihrer Gemfile(5) erfüllt.
Als Nächstes ändern Sie Ihre Gemfile(5) wie folgt:
source 'https://rubygems.org'
gem 'actionpack', '3.0.0.rc'
gem 'activemerchant'Das Gem actionpack 3.0.0.rc hat eine Reihe neuer Abhängigkeiten und aktualisiert die activesupport-Abhängigkeit auf = 3.0.0.rc und die Rack-Abhängigkeit zu ~> 1.2.1.
Wenn Sie bundle install ausführen, stellt Bundler fest, dass Sie das Gem actionpack geändert haben, nicht jedoch das Gem activemerchant. Es bewertet die Edelsteine, die derzeit zur Erfüllung seiner Anforderungen verwendet werden:
Wird auch verwendet, um eine Abhängigkeit in activemerchant zu erfüllen, die nicht aktualisiert wird
wird derzeit nicht zur Erfüllung einer anderen Abhängigkeit verwendet
Da Sie nicht ausdrücklich darum gebeten haben, activemerchant zu aktualisieren, können Sie nicht erwarten, dass es nach der Aktualisierung von actionpack plötzlich nicht mehr funktioniert. Um jedoch die neue activesupport 3.0.0.rc-Abhängigkeit von Actionpack zu erfüllen, muss eine seiner Abhängigkeiten aktualisiert werden.
Obwohl activemerchant eine sehr lose Abhängigkeit deklariert, die theoretisch mit activesupport 3.0.0.rc übereinstimmt, behandelt Bundler Gems in Ihrer Gemfile(5), die sich nicht geändert haben, als atomare Einheit zusammen mit ihren Abhängigkeiten. In diesem Fall wird die activemerchant-Abhängigkeit als activemerchant 1.7.1 + activesupport 2.3.8 behandelt, sodass bundle install meldet, dass keine Aktualisierung möglich ist Actionpack.
Um actionpack explizit zu aktualisieren, einschließlich seiner Abhängigkeiten, von denen andere Gems in der Gemfile(5) noch abhängen, führen Sie bundle update actionpack aus (siehe bundle update(1)<).
Zusammenfassung: Im Allgemeinen sollten Sie nach einer Änderung an der Gemfile(5) zunächst versuchen, Bundle Install auszuführen, um sicherzustellen, dass kein anderes Gem in der Gemfile( 5) ist von der Änderung betroffen. Wenn das nicht funktioniert, führen Sie bundle update(1) bundle-update.1.html aus.
Gem-Installationsdokumente http://guides.rubygems.org/rubygems-basics/#installing-gems
Rubygems-Signaturdokumente http://guides.rubygems.org/security/