bundle-update - Aggiorna le tue gemme alle ultime versioni disponibili
bundle update *gems [--all] [--group=NAME] [--source=NAME] [--local] [--ruby] [--bundler[=VERSION]] [--full-index] [--jobs=JOBS] [--quiet] [--patch|--minor|--major] [--redownload] [--strict] [--conservative]
Aggiorna le gemme specificate (tutte le gemme, se viene utilizzato il flag --all), ignorando le gemme precedentemente installate specificate in Gemfile.lock. In generale, dovresti usare bundle install(1) bundle-install.1.html per installare le stesse identiche gemme e versioni su tutte le macchine.
Useresti bundle update per aggiornare esplicitamente la versione di un gem.
Aggiorna tutte le gemme specificate in Gemfile.
Aggiorna solo le gemme nel gruppo specificato. Ad esempio, puoi aggiornare tutte le gemme nel gruppo di sviluppo con bundle update --group development. Puoi anche chiamare bundle update rails --group test per aggiornare la gem rails e tutte le gem nel gruppo di test, ad esempio.
Il nome di una sorgente :git o :path usata nel Gemfile(5). Ad esempio, con una sorgente :git di http://github.com/rails/rails.git, chiameresti bundle update --source rails
Non tentare di recuperare le gemme da remoto e utilizzare invece la cache delle gemme.
Aggiorna la versione bloccata di Ruby alla versione corrente di Ruby.
Aggiorna la versione bloccata del bundler alla versione richiamata del bundler.
Ripiegare sull'utilizzo dell'indice a file singolo di tutte le gemme.
Specificare il numero di processi da eseguire in parallelo. Il valore predefinito è il numero di processori disponibili.
Riprova le richieste di rete o git non riuscite per number volte.
Visualizza solo avvisi ed errori.
Forza il download di ogni gemma.
Preferisci l'aggiornamento solo alla prossima versione della patch.
Preferisci l'aggiornamento solo alla successiva versione minore.
Preferisci l'aggiornamento alla prossima versione principale (impostazione predefinita).
Non consentire l'aggiornamento di alcuna gemma dopo l'ultima --patch | --minore | --maggiore.
Utilizzare il comportamento di aggiornamento conservativo dell'installazione in bundle e non consentire l'aggiornamento delle dipendenze indirette.
Se esegui bundle update --all, il bundler ignorerà qualsiasi gem precedentemente installato e risolverà nuovamente tutte le dipendenze in base alle ultime versioni di tutte le gemme disponibili nelle fonti.
Considera il seguente Gemfile(5):
source "https://rubygems.org"
gem "rails", "3.0.0.rc"
gem "nokogiri"Quando esegui bundle install(1) bundle-install.1.html la prima volta, il bundler risolverà tutte le dipendenze, fino in fondo, e installerà ciò di cui hai bisogno:
Fetching gem metadata from https://rubygems.org/.........
Resolving dependencies...
Installing builder 2.1.2
Installing abstract 1.0.0
Installing rack 1.2.8
Using bundler 1.7.6
Installing rake 10.4.0
Installing polyglot 0.3.5
Installing mime-types 1.25.1
Installing i18n 0.4.2
Installing mini_portile 0.6.1
Installing tzinfo 0.3.42
Installing rack-mount 0.6.14
Installing rack-test 0.5.7
Installing treetop 1.4.15
Installing thor 0.14.6
Installing activesupport 3.0.0.rc
Installing erubis 2.6.6
Installing activemodel 3.0.0.rc
Installing arel 0.4.0
Installing mail 2.2.20
Installing activeresource 3.0.0.rc
Installing actionpack 3.0.0.rc
Installing activerecord 3.0.0.rc
Installing actionmailer 3.0.0.rc
Installing railties 3.0.0.rc
Installing rails 3.0.0.rc
Installing nokogiri 1.6.5
Bundle complete! 2 Gemfile dependencies, 26 gems total.
Use `bundle show [gemname]` to see where a bundled gem is installed.Come puoi vedere, anche se hai due gemme nel Gemfile (5), la tua applicazione ha bisogno di 26 gemme diverse per funzionare. Bundler ricorda le versioni esatte installate in Gemfile.lock. La prossima volta che esegui bundle install(1) bundle-install.1.html, bundler salta la risoluzione delle dipendenze e installa gli stessi gems installati l'ultima volta.
Dopo aver archiviato Gemfile.lock nel controllo della versione e averlo clonato su un'altra macchina, l'esecuzione di bundle install(1) bundle-install.1.html ancora installa le gemme che hai installato l'ultima volta. Non devi preoccuparti che una nuova versione di erubis o mail cambi le gemme che usi.
Tuttavia, di tanto in tanto, potresti voler aggiornare le gemme che stai utilizzando alle versioni più recenti che corrispondono ancora alle gemme nel tuo Gemfile(5).
Per fare ciò, esegui bundle update --all, che ignorerà Gemfile.lock e risolverà nuovamente tutte le dipendenze. Tieni presente che questo processo può comportare un insieme significativamente diverso delle 25 gemme, in base ai requisiti delle nuove gemme che gli autori delle gemme hanno rilasciato dall'ultima volta che hai eseguito bundle update --all.
A volte, vuoi aggiornare una singola gemma nel Gemfile(5) e lasciare il resto delle gemme che hai specificato bloccato alle versioni nel Gemfile.lock.
Ad esempio, nello scenario precedente, immagina che nokogiri rilasci la versione 1.4.4 e tu desideri aggiornarla senza aggiornare Rails e tutti i le sue dipendenze. Per fare ciò, esegui bundle update nokogiri.
Bundler aggiornerà nokogiri e tutte le sue dipendenze, ma lascerà stare Rails e le sue dipendenze.
A volte, più gemme dichiarate nel tuo Gemfile(5) sono soddisfatte dalla stessa dipendenza di secondo livello. Ad esempio, considera il caso di thin e rack-perftools-profiler.
source "https://rubygems.org"
gem "thin"
gem "rack-perftools-profiler"La gemma thin dipende da rack >= 1.0, mentre rack-perftools-profiler dipende da rack ~> 1.0 . Se esegui l'installazione in bundle, ottieni:
Fetching source index for https://rubygems.org/
Installing daemons (1.1.0)
Installing eventmachine (0.12.10) with native extensions
Installing open4 (1.0.1)
Installing perftools.rb (0.4.7) with native extensions
Installing rack (1.2.1)
Installing rack-perftools_profiler (0.0.2)
Installing thin (1.2.7) with native extensions
Using bundler (1.0.0.rc.3)In questo caso, le due gemme hanno il proprio set di dipendenze, ma condividono rack in comune. Se esegui bundle update thin, bundler aggiornerà demoni, eventmachine e rack, che sono dipendenze di thin, ma non open4 o perftools.rb, che sono dipendenze di rack-perftools_profiler. Tieni presente che bundle update thin aggiornerà rack anche se è anche una dipendenza di rack-perftools_profiler.
In breve, per impostazione predefinita, quando aggiorni una gem usando bundle update, il bundler aggiornerà tutte le dipendenze di quella gem, incluse quelle che sono anche dipendenze di un'altra gem.
Per impedire l'aggiornamento delle dipendenze indirette, prima della versione 1.14 l'unica opzione era il comportamento CONSERVATIVE UPDATING in bundle install(1) bundle-install.1.html:
In questo scenario, l'aggiornamento manuale della versione thin nel Gemfile(5) e quindi l'esecuzione di bundle install(1) bundle-install.1.html aggiornerà solo demoni e eventmachine, ma non rack. Per ulteriori informazioni, vedere la sezione AGGIORNAMENTO CONSERVATIVO di bundle install(1) bundle-install.1.html.
A partire dalla 1.14, specificando l'opzione --conservative si impedirà anche l'aggiornamento delle dipendenze indirette.
La versione 1.14 ha introdotto 4 opzioni a livello di patch che influenzeranno il modo in cui vengono risolte le versioni delle gemme. È possibile utilizzare una delle seguenti opzioni: --patch, --minor o --major. --strict può essere aggiunto per influenzare ulteriormente la risoluzione.
Preferisci l'aggiornamento solo alla prossima versione della patch.
Preferisci l'aggiornamento solo alla successiva versione minore.
Preferisci l'aggiornamento alla prossima versione principale (impostazione predefinita).
Non consentire l'aggiornamento di alcuna gemma dopo l'ultima --patch | --minore | --maggiore.
Quando Bundler sta risolvendo quali versioni utilizzare per soddisfare i requisiti dichiarati nel Gemfile o nelle gem parent, cerca tutte le versioni disponibili, filtra le versioni che non soddisfano il requisito e quindi, per impostazione predefinita, le ordina dalla più recente alla più antico, considerandoli in quest'ordine.
Fornire una delle opzioni a livello di patch (ad es. --patch) cambia l'ordinamento delle versioni soddisfacenti, facendo in modo che Bundler consideri l'ultima --patch o - -minor versione disponibile prima di altre versioni. Si noti che le versioni al di fuori del livello di patch dichiarato potrebbero ancora essere risolte, se necessario, per trovare un grafico delle dipendenze adatto.
Ad esempio, se gem 'foo' è bloccato su 1.0.2, senza alcun requisito gem definito nel Gemfile, ed esistono tutte le versioni 1.0.3, 1.0.4, 1.1.0, 1.1.1, 2.0.0, l'impostazione predefinita l'ordine di preferenza predefinito (--major) sarà "2.0.0, 1.1.1, 1.1.0, 1.0.4, 1.0.3, 1.0.2".
Se viene utilizzata l'opzione --patch, l'ordine di preferenza cambierà in "1.0.4, 1.0.3, 1.0.2, 1.1.1, 1.1.0, 2.0.0".
Se viene utilizzata l'opzione --minor, l'ordine di preferenza cambierà in "1.1.1, 1.1.0, 1.0.4, 1.0.3, 1.0.2, 2.0.0".
La combinazione dell'opzione --strict con una qualsiasi delle opzioni a livello di patch rimuoverà tutte le versioni oltre l'ambito dell'opzione a livello di patch, per garantire che nessuna gemma venga aggiornata fino a quel punto.
Per continuare l'esempio precedente, se vengono utilizzate entrambe le opzioni --patch e --strict, le versioni disponibili per la risoluzione sarebbero "1.0.4, 1.0.3, 1.0 .2". Se vengono utilizzati --minor e --strict, sarà "1.1.1, 1.1.0, 1.0.4, 1.0.3, 1.0.2".
I requisiti Gem come definiti nel Gemfile saranno ancora il primo fattore determinante per quali versioni sono disponibili. Se il requisito gem per foo nel Gemfile è '~> 1.0', ciò otterrà la stessa cosa che fornire --minor e --strict< opzioni.
Date le seguenti specifiche della gemma:
foo 1.4.3, requires: ~> bar 2.0
foo 1.4.4, requires: ~> bar 2.0
foo 1.4.5, requires: ~> bar 2.1
foo 1.5.0, requires: ~> bar 2.1
foo 1.5.1, requires: ~> bar 3.0
bar with versions 2.0.3, 2.0.4, 2.1.0, 2.1.1, 3.0.0Gemfile:
gem 'foo'Gemfile.lock:
foo (1.4.3)
bar (~> 2.0)
bar (2.0.3)Casi:
# Command Line Result
------------------------------------------------------------
1 bundle update --patch 'foo 1.4.5', 'bar 2.1.1'
2 bundle update --patch foo 'foo 1.4.5', 'bar 2.1.1'
3 bundle update --minor 'foo 1.5.1', 'bar 3.0.0'
4 bundle update --minor --strict 'foo 1.5.0', 'bar 2.1.1'
5 bundle update --patch --strict 'foo 1.4.4', 'bar 2.0.4'Nel caso 1, bar viene aggiornato alla 2.1.1, un aumento della versione minore, poiché la dipendenza da foo 1.4.5 lo richiedeva.
Nel caso 2, solo foo deve essere sbloccato, ma anche bar può muoversi perché non è una dipendenza dichiarata nel Gemfile.
Nel caso 3, bar sale di un'intera versione principale, perché ora è preferibile un aumento minore per foo, e quando va a 1.5.1, richiede 3.0.0 di bar.
Nel caso 4, foo è preferito fino a una versione minore, ma 1.5.1 non funzionerà perché il flag --strict rimuove la barra 3.0.0 dalla considerazione poiché è un incremento importante.
Nel caso 5, sia foo che bar hanno tutti gli incrementi minori o maggiori rimossi dalla considerazione a causa del flag --strict, quindi il massimo che possono spostare è fino a 1.4.4 e 2.0.4.
In generale, quando si lavora con un'applicazione gestita con bundler, è necessario utilizzare il seguente flusso di lavoro:
Dopo aver creato il tuo Gemfile(5) per la prima volta, esegui
bundle install
Controlla il Gemfile.lock risultante nel controllo della versione
git add Gemfile.lock
Quando estrai questo repository su un'altra macchina di sviluppo, esegui
bundle install
Durante il check-out di questo repository su una macchina di distribuzione, esegui
bundle install --deployment
Dopo aver modificato Gemfile(5) per riflettere una dipendenza nuova o aggiornata, eseguire
bundle install
Assicurati di controllare il Gemfile.lock aggiornato nel controllo della versione
git add Gemfile.lock
Se bundle install(1) bundle-install.1.html segnala un conflitto, aggiorna manualmente i gem specifici che hai modificato nel Gemfile(5)
bundle update rails thin
Se vuoi aggiornare tutte le gemme alle ultime versioni possibili che corrispondono ancora alle gemme elencate nel Gemfile(5), esegui
bundle update --all