Grundlegendes zur Gemfile.lock-Datei

Nach dem Ausführen des bundle installBefehls wird 'Gemfile.lock ' im Arbeitsverzeichnis erstellt. Was bedeuten die Anweisungen in dieser Datei?

Nehmen wir zum Beispiel die folgende Datei:

PATH
  remote: .
  specs:
    gem_one (0.0.1)

GEM
  remote: http://example.org/
  specs:
    gem_two (0.0.2)
    gem_three (0.0.3)
      gem_four (0.0.4)

PLATFORMS
  platform

DEPENDENCIES
  gem_two
  gem_one!

Was beschreiben ' PATH ', ' GEM ', ' PLATFORMS ' und ' DEPENDENCIES '? Sind alle erforderlich?

Was sollte die Unterverzeichnisse ' remote ' und ' specs ' enthalten?

Was bedeutet das Ausrufezeichen nach dem Edelsteinnamen in der Gruppe " ABHÄNGIGKEITEN "?

Weitere Informationen finden Sie auf der Bundler-Website (Hervorhebung unten zur Vereinfachung hinzugefügt):

Nachdem Sie Ihre Anwendung für eine Weile entwickelt haben, checken Sie die Anwendung zusammen mit dem Snapshot Gemfile und Gemfile.lock ein . Jetzt enthält Ihr Repository eine Aufzeichnung der genauen Versionen aller Edelsteine, die Sie verwendet haben, als Sie das letzte Mal sicher waren, dass die Anwendung funktioniert hat ...

Dies ist wichtig: Mit Gemfile.lock wird Ihre Anwendung zu einem einzigen Paket aus Ihrem eigenen Code und dem Code von Drittanbietern, der ausgeführt wurde, als Sie das letzte Mal sicher waren, dass alles funktioniert hat. Die Angabe genauer Versionen des Codes von Drittanbietern, von dem Sie in Ihrer Gemfile abhängig sind, bietet nicht die gleiche Garantie, da Gems normalerweise eine Reihe von Versionen für ihre Abhängigkeiten deklarieren.

In Bezug auf das Ausrufezeichen habe ich gerade herausgefunden, dass es sich um Edelsteine ​​handelt, die über :gitz

gem "foo", :git => "git@github.com:company/foo.git"

Ich habe in den letzten Monaten viel mit Gemfiles und Gemfile.locks herumgespielt, während ich ein automatisiertes Tool zur Aktualisierung von Abhängigkeiten ^{1 erstellt habe} . Das Folgende ist alles andere als endgültig, aber es ist ein guter Ausgangspunkt für das Verständnis des Gemfile.lock-Formats. Möglicherweise möchten Sie auch den Quellcode für Bundlers Lockfile-Parser überprüfen .

Die folgenden Überschriften finden Sie in einer von Bundler 1.x generierten Sperrdatei:

GEM (optional, aber sehr häufig)

Dies sind Abhängigkeiten, die von einem Rubygems-Server stammen. Dies kann der Hauptindex von Rubygems bei Rubygems.org sein, oder es kann sich um einen benutzerdefinierten Index handeln, wie er beispielsweise von Gemfury und anderen erhältlich ist. In diesem Abschnitt sehen Sie:

• remote: eine oder mehrere Zeilen, die den Speicherort der Rubygems-Indizes angeben
• specs: Eine Liste der Abhängigkeiten mit ihrer Versionsnummer und den Einschränkungen für alle Unterabhängigkeiten

GIT (optional)

Dies sind Abhängigkeiten, die von einer bestimmten Git-Fernbedienung stammen. Sie sehen einen anderen dieser Abschnitte für jede Git-Fernbedienung und in jedem Abschnitt sehen Sie:

• remote:die Git-Fernbedienung. Z.B,git@github.com:rails/rails
• revision: Die Festschreibungsreferenz, für die Gemfile.lock gesperrt ist
• tag: (optional) das in der Gemfile angegebene Tag
• specs: Die auf dieser Fernbedienung gefundene Git-Abhängigkeit mit ihrer Versionsnummer und die Einschränkungen für eventuelle Unterabhängigkeiten

PFAD (optional)

Dies sind Abhängigkeiten, die von einer bestimmten pathin der Gem-Datei bereitgestellten Abhängigkeit stammen . In jedem Abschnitt wird für jede Pfadabhängigkeit ein anderer Abschnitt angezeigt. In jedem Abschnitt wird Folgendes angezeigt:

• remote:der Weg. Z.B,plugins/vendored-dependency
• specs: Die auf dieser Fernbedienung gefundene Git-Abhängigkeit mit ihrer Versionsnummer und die Einschränkungen für eventuelle Unterabhängigkeiten

PLATTFORMEN

Die Ruby-Plattform, gegen die Gemfile.lock generiert wurde. Wenn Abhängigkeiten in der Gemfile eine Plattform angeben, werden sie nur dann in die Gemfile.lock aufgenommen, wenn die Lockfile auf dieser Plattform generiert wird (z. B. durch eine Installation).

ABHÄNGIGKEITEN

Eine Liste der Abhängigkeiten, die in angegeben sind Gemfile, sowie die dort angegebene Versionsbeschränkung.

Abhängigkeiten, die mit einer anderen Quelle als dem Rubygems-Hauptindex angegeben wurden (z. B. Git-Abhängigkeiten, pfadbasierte Abhängigkeiten), haben eine, !was bedeutet, dass sie an diese Quelle ² "angeheftet" sind (obwohl man manchmal in der Gemfile nachsehen muss, um sie zu bestimmen).

RUBINVERSION (optional)

Die Ruby-Version, die in der Gemfile angegeben wurde, als diese Gemfile.lock erstellt wurde. Wenn .ruby_versionstattdessen eine Ruby-Version in einer Datei angegeben ist, ist dieser Abschnitt nicht vorhanden (da Bundler die Datei Gemfile / Gemfile.lock als unabhängig von der Ruby-Version des Installationsprogramms betrachtet).

BUNDLED WITH (Bundler> = v1.10.x)

Die Version von Bundler, mit der Gemfile.lock erstellt wurde. Wird verwendet, um Installateure daran zu erinnern, ihre Bundler-Version zu aktualisieren, wenn sie älter als die Version ist, mit der die Datei erstellt wurde.

PLUGIN SOURCE (optional und sehr selten)

Theoretisch kann eine Gem-Datei Bundler-Plugins sowie Gems ³ angeben , die dann hier aufgelistet werden. In der Praxis sind mir seit Juli 2017 keine verfügbaren Plugins bekannt. Dieser Teil von Bundler befindet sich noch in der aktiven Entwicklung!

1. https://dependabot.com
2. https://github.com/bundler/bundler/issues/4631
3. http://andre.arko.net/2012/07/23/towards-a-bundler-plugin-system/

Bundler ist ein Gem-Manager, der eine konsistente Umgebung für Ruby-Projekte bietet, indem er die genauen Gems und Versionen verfolgt und installiert, die benötigt werden.

Gemfile und Gemfile.lock sind Hauptprodukte von Bundler gem (Bundler selbst ist ein Juwel).

Gemfile enthält Ihre Projektabhängigkeit von Gem (s), die Sie manuell mit den angegebenen Versionen erwähnen. Diese Inturn hängt jedoch von anderen Gem (s) ab, die vom Bundler automatisch aufgelöst werden.

Gemfile.lock enthält eine vollständige Momentaufnahme aller Edelsteine ​​in Gemfile sowie die damit verbundene Abhängigkeit.

Wenn Sie die Bundle-Installation zum ersten Mal aufrufen , wird diese Gemfile.lock erstellt und diese Datei in allen nachfolgenden Aufrufen zur Bundle-Installation verwendet. Dadurch wird sichergestellt, dass alle Abhängigkeiten installiert sind, und die Abhängigkeitsinstallation wird übersprungen.

Gleiches passiert, wenn Sie Ihren Code für verschiedene Computer freigeben

Sie teilen Ihr Gemfile.lock zusammen mit Gemfile. Wenn Sie die Bundle-Installation auf einem anderen Computer ausführen, verweist es auf Ihr Gemfile.lock und überspringt den Schritt zur Auflösung der Abhängigkeit. Stattdessen werden alle abhängigen Gems installiert, die Sie auf dem verwendet haben Originalmaschine, die die Konsistenz über mehrere Maschinen hinweg gewährleistet

Warum müssen wir die Konsistenz auf mehreren Maschinen aufrechterhalten?

• Das Ausführen verschiedener Versionen auf verschiedenen Computern kann zu fehlerhaftem Code führen

• Angenommen, Ihre App hat die Version 1.5.3 verwendet und funktioniert vor 14 Monaten
  ohne Probleme. Sie versuchen,
  ohne Gemfile.lock auf einem anderen Computer zu installieren. Jetzt erhalten Sie die Version 1.5.8. Möglicherweise ist es mit der neuesten Version einiger Juwelen defekt und Ihre Anwendung schlägt
  fehl. Die Aufrechterhaltung der Konsistenz ist von größter Bedeutung (bevorzugte
  Praxis).

Es ist auch möglich, Edelsteine ​​in Gemfile.lock mithilfe des Bundle-Updates zu aktualisieren .

Dies basiert auf dem Konzept der konservativen Aktualisierung

Für mich sieht es so aus, als würde PATH die Abhängigkeiten der ersten Generation direkt von Ihrer Gemspec auflisten, während GEM Abhängigkeiten der zweiten Generation (dh wovon Ihre Abhängigkeiten abhängen) und die Abhängigkeiten aus Ihrer Gemfile auflistet. PATH :: remote basiert darauf, .dass es sich auf eine lokale Gemspec im aktuellen Verzeichnis stützte, um herauszufinden, was in PATH :: spec gehört, während GEM :: remote dies ist rubygems.org, da es dort hingehen musste, um herauszufinden, was in GEM :: gehört. spec.

In einem Rails-Plugin sehen Sie einen PATH-Abschnitt, jedoch nicht in einer Rails-App. Da die App keine gemspec-Datei hat, gibt es nichts, was in PATH eingefügt werden könnte.

In Bezug auf ABHÄNGIGKEITEN gibt gembundler.com Folgendes an:

Runtime dependencies in your gemspec are treated like base dependencies, 
and development dependencies are added by default to the group, :development

Das Gemfile von generiert rails plugin new my_pluginetwas Ähnliches:

# Bundler will treat runtime dependencies like base dependencies, and
# development dependencies will be added by default to the :development group.

Was dies bedeutet ist, dass der Unterschied zwischen

s.add_development_dependency "july" # (1)

und

s.add_dependency "july" # (2)

ist, dass (1) nur "Juli" in Gemfile.lock (und damit in der Anwendung) in einer Entwicklungsumgebung enthält. Wenn Sie also laufen bundle install, sehen Sie "Juli" nicht nur unter PATH, sondern auch unter DEPENDENCIES, sondern nur in der Entwicklung. In der Produktion wird es überhaupt nicht da sein. Wenn Sie jedoch (2) verwenden, sehen Sie "Juli" nur in PATH, nicht in DEPENDENCIES, aber es wird angezeigt, wenn Sie bundle installaus einer Produktionsumgebung stammen (dh in einem anderen Juwel, das Ihre als Abhängigkeit enthält), nicht nur Entwicklung.

Dies sind nur meine Beobachtungen und ich kann nicht vollständig erklären, warum dies so ist, aber ich begrüße weitere Kommentare.

Es scheint kein klares Dokument über das Gemfile.lockFormat zu sprechen . Vielleicht liegt es daran, dass Gemfile.lockes nur von Bundle intern verwendet wird.

Da es sich jedoch Gemfile.lockum eine Momentaufnahme von handelt Gemfile, bedeutet dies, dass alle Informationen von Gemfile(oder vom Standardwert, falls nicht in angegeben Gemfile) stammen sollten.

Denn GEMes listet alle Abhängigkeiten auf, die Sie direkt oder indirekt in die einführen Gemfile. remoteunter gibt an GEM, woher die Edelsteine ​​stammen, die von der Quelle in angegeben werden Gemfile.

Wenn ein Edelstein nicht abgerufen wird remote, PATHteilt er dem Ort mit, wo er gefunden werden soll. PATHDie Informationen stammen vom Pfad in, Gemfilewenn Sie eine Abhängigkeit deklarieren.

Und PLATFORMist von hier .

Denn DEPENDENCIESes ist die Momentaufnahme von Abhängigkeiten, die durch ein Bundle aufgelöst werden.

Was bedeutet das Ausrufezeichen nach dem Edelsteinnamen in der Gruppe "ABHÄNGIGKEITEN"?

Das Ausrufezeichen wird angezeigt, wenn der Edelstein mit einer anderen Quelle als " https://rubygems.org " installiert wurde .