Comprensione del file Gemfile.lock

Dopo aver eseguito il bundle installcomando, 'Gemfile.lock ' viene creato nella directory di lavoro. Cosa significano le direttive all'interno di quel file?

Ad esempio, prendiamo il seguente file:

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!

Cosa descrivono " PERCORSO ", " GEM ", " PIATTAFORME " e " DIPENDENZE "? Sono richiesti tutti?

Cosa dovrebbe contenere le sottodirettive " remote " e " specs "?

Che cosa significa il punto esclamativo dopo il nome della gemma nel gruppo " DEPENDENZE "?

Puoi trovare ulteriori informazioni nel sito Web del bundler (enfasi aggiunta di seguito per comodità):

Dopo aver sviluppato l'applicazione per un po ', controlla l'applicazione insieme allo snapshot Gemfile e Gemfile.lock . Ora, il tuo repository ha un registro delle versioni esatte di tutte le gemme che hai usato l'ultima volta che sai per certo che l'applicazione ha funzionato ...

Questo è importante: Gemfile.lock trasforma la tua applicazione in un unico pacchetto sia del tuo codice che del codice di terze parti che è stato eseguito l'ultima volta che sei sicuro che tutto ha funzionato. Specificare le versioni esatte del codice di terze parti da cui dipendi nel tuo Gemfile non fornirebbe la stessa garanzia, poiché le gemme di solito dichiarano un intervallo di versioni per le loro dipendenze.

per quanto riguarda il punto esclamativo che ho appena scoperto è su gemme recuperate tramite :git, ad es

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

Ho passato gli ultimi mesi a scherzare con Gemfiles e Gemfile.locks molto mentre costruivo uno strumento di aggiornamento automatico delle dipendenze ¹ . Il seguito è tutt'altro che definitivo, ma è un buon punto di partenza per comprendere il formato Gemfile.lock. Potresti anche voler controllare il codice sorgente per il parser del file di blocco di Bundler .

Troverai le seguenti intestazioni in un file di blocco generato da Bundler 1.x:

GEM (opzionale ma molto comune)

Queste sono dipendenze provenienti da un server Rubygems. Questo potrebbe essere il principale indice di Rubygems, su Rubygems.org, oppure potrebbe essere un indice personalizzato, come quelli disponibili da Gemfury e altri. All'interno di questa sezione vedrai:

• remote: una o più righe che specificano la posizione dell'indice o degli indici di Rubygems
• specs: un elenco di dipendenze, con il loro numero di versione e i vincoli su eventuali sottodipendenze

GIT (opzionale)

Queste sono dipendenze provenienti da un dato telecomando git. Vedrai una diversa di queste sezioni per ogni telecomando git e all'interno di ogni sezione vedrai:

• remote:il telecomando git. Per esempio,git@github.com:rails/rails
• revision: il riferimento di commit a cui Gemfile.lock è bloccato
• tag: (facoltativo) il tag specificato nel Gemfile
• specs: la dipendenza git trovata su questo telecomando, con il suo numero di versione e i vincoli su eventuali sottodipendenze

PERCORSO (opzionale)

Queste sono dipendenze provenienti da un dato path, fornite nel Gemfile. Vedrai una diversa di queste sezioni per ogni dipendenza del percorso e all'interno di ogni sezione vedrai:

• remote:il sentiero. Per esempio,plugins/vendored-dependency
• specs: la dipendenza git trovata su questo telecomando, con il suo numero di versione e i vincoli su eventuali sottodipendenze

PIATTAFORME

La piattaforma Ruby contro cui è stato generato Gemfile.lock. Se alcune dipendenze nel Gemfile specificano una piattaforma, queste saranno incluse nel Gemfile.lock solo quando il lockfile viene generato su quella piattaforma (ad es. Attraverso un'installazione).

DIPENDENZE

Un elenco delle dipendenze specificate in Gemfile, insieme al vincolo di versione specificato lì.

Le dipendenze specificate con una fonte diversa dall'indice principale di Rubygems (ad es. Dipendenze git, basate sul percorso, dipendenze) hanno un !significato che significa che sono "bloccate" a quella fonte ² (anche se a volte si deve cercare nel Gemfile per determinare in).

VERSIONE RUBY (opzionale)

La versione di Ruby specificata nel Gemfile, quando è stato creato questo Gemfile.lock. Se in un .ruby_versionfile viene specificata una versione di Ruby, questa sezione non sarà presente (poiché Bundler considererà Gemfile / Gemfile.lock agnostico rispetto alla versione di Ruby dell'installatore).

CONFEZIONATO CON (Bundler> = v1.10.x)

La versione di Bundler utilizzata per creare Gemfile.lock. Utilizzato per ricordare agli installatori di aggiornare la loro versione di Bundler, se è precedente alla versione che ha creato il file.

PLUGIN SOURCE (opzionale e molto raro)

In teoria, un Gemfile può specificare plugin Bundler, così come gemme ³ , che sarebbero quindi elencati qui. In pratica, non sono a conoscenza di plug-in disponibili, a partire da luglio 2017. Questa parte di Bundler è ancora in fase di sviluppo attivo!

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 è un gestore gemme che fornisce un ambiente coerente per i progetti Ruby monitorando e installando le gemme e le versioni esatte necessarie.

Gemfile e Gemfile.lock sono prodotti primari forniti dalla gemma Bundler (Bundler stesso è una gemma).

Gemfile contiene la dipendenza del tuo progetto dalle gemme, che menzioni manualmente con le versioni specificate, ma quelle gemme inturn dipendono da altre gemme che vengono risolte automaticamente dal bundler.

Gemfile.lock contiene un'istantanea completa di tutte le gemme in Gemfile insieme alla dipendenza associata.

Quando si chiama l' installazione del bundle per la prima volta , viene creato questo Gemfile.lock e si utilizza questo file in tutte le chiamate successive per installare il bundle, il che garantisce che tutte le dipendenze siano installate e salterà l'installazione delle dipendenze.

Lo stesso succede quando condividi il tuo codice con macchine diverse

Condividi Gemfile.lock insieme a Gemfile, quando esegui l'installazione in bundle su un'altra macchina farà riferimento al tuo Gemfile.lock e salterà il passaggio di risoluzione della dipendenza, invece installerà tutte le stesse gemme dipendenti che hai usato sul macchina originale, che mantiene la coerenza tra più macchine

Perché dobbiamo mantenere la coerenza su più macchine?

• L'esecuzione di versioni diverse su macchine diverse potrebbe causare la rottura del codice

• Supponiamo che la tua app abbia utilizzato la versione 1.5.3 e funzioni 14 mesi fa
  senza problemi e provi a installarla su un altro computer
  senza Gemfile.lock ora ottieni la versione 1.5.8. Forse è rotto con l'ultima versione di alcune gemme e la tua applicazione
  fallirà. Mantenere la coerenza è della massima importanza (
  pratica preferita ).

È anche possibile aggiornare le gemme in Gemfile.lock usando l' aggiornamento del bundle .

Questo si basa sul concetto di aggiornamento conservativo

Mi sembra che PATH elenchi le dipendenze di prima generazione direttamente dal tuo gemspec, mentre GEM elenca le dipendenze di seconda generazione (cioè da cosa dipendono le tue dipendenze) e quelle dal tuo Gemfile. PERCORSO :: remote è .perché si basava su un gemspec locale nella directory corrente per scoprire cosa appartiene a PATH :: spec, mentre GEM :: remote è rubygems.org, poiché è lì che doveva andare per scoprire cosa appartiene a GEM :: spec.

In un plug-in Rails, vedrai una sezione PATH, ma non in un'app Rails. Poiché l'app non ha un file gemspec, non ci sarebbe nulla da mettere in PERCORSO.

Per quanto riguarda DEPENDENCIES , gembundler.com afferma:

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

Il Gemfile generato da rails plugin new my_plugindice qualcosa di simile:

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

Ciò significa che la differenza tra

s.add_development_dependency "july" # (1)

e

s.add_dependency "july" # (2)

è che (1) includerà "luglio" solo in Gemfile.lock (e quindi nell'applicazione) in un ambiente di sviluppo. Quindi, quando corri bundle install, vedrai "luglio" non solo sotto PATH ma anche sotto DEPENDENCIES, ma solo in fase di sviluppo. In produzione, non ci sarà affatto. Tuttavia, quando usi (2), vedrai "luglio" solo in PERCORSO, non in DEPENDENCIES, ma verrà visualizzato quando provieni bundle installda un ambiente di produzione (ovvero in qualche altro gioiello che include il tuo come dipendenza), non solo sviluppo.

Queste sono solo le mie osservazioni e non posso spiegare appieno perché tutto ciò sia così, ma accolgo con favore ulteriori commenti.

Non sembra un documento chiaro che parli sul Gemfile.lockformato. Forse è perché Gemfile.lockviene utilizzato solo dal bundle internamente.

Tuttavia, poiché Gemfile.lockè un'istantanea di Gemfile, ciò significa che tutte le sue informazioni dovrebbero provenire Gemfile(o dal valore predefinito se non specificato in Gemfile).

Per GEM, elenca tutte le dipendenze introdotte direttamente o indirettamente nel file Gemfile. remoteunder GEMindica dove ottenere le gemme, che è specificato dalla fonte in Gemfile.

Se una gemma non viene prelevata remote, PATHindica la posizione per trovarla. PATHLe informazioni fornite provengono dal percorso in Gemfilecui si dichiara una dipendenza.

Ed PLATFORMè di qui .

Perché DEPENDENCIESè l'istantanea delle dipendenze risolte dal bundle.

Cosa significa il punto esclamativo dopo il nome della gemma nel gruppo "DEPENDECIES"?

Il punto esclamativo appare quando la gemma è stata installata utilizzando una fonte diversa da " https://rubygems.org ".