bundle-update - Actualiza tus gemas a las últimas versiones disponibles
bundle update *gems [--all] [--group=NAME] [--source=NAME] [--local] [--ruby] [--bundler[=VERSION]] [--full-index] [--jobs=JOBS] [--quiet] [--patch|--minor|--major] [--redownload] [--strict] [--conservative]
Actualice las gemas especificadas (todas las gemas, si se usa el indicador --all), ignorando las gemas previamente instaladas especificadas en Gemfile.lock. En general, debe usar bundle install(1) bundle-install.1.html para instalar exactamente las mismas gemas y versiones en todas las máquinas.
Usaría actualización de paquete para actualizar explícitamente la versión de una gema.
Actualice todas las gemas especificadas en Gemfile.
Solo actualice las gemas en el grupo especificado. Por ejemplo, puede actualizar todas las gemas en el grupo de desarrollo con actualización de paquete --desarrollo de grupo. También puede llamar a rieles de actualización de paquete --prueba de grupo para actualizar la gema de rieles y todas las gemas en el grupo de prueba, por ejemplo.
El nombre de una fuente :git o :path utilizada en el Gemfile(5). Por ejemplo, con una fuente :git de http://github.com/rails/rails.git, llamarías a bundle update --source rails
No intente obtener gemas de forma remota y use el caché de gemas en su lugar.
Actualice la versión bloqueada de Ruby a la versión actual de Ruby.
Actualice la versión bloqueada del paquete a la versión del paquete invocado.
Vuelva a usar el índice de un solo archivo de todas las gemas.
Especifique el número de trabajos que se ejecutarán en paralelo. El valor predeterminado es el número de procesadores disponibles.
Vuelva a intentar las solicitudes fallidas de red o git por número veces.
Solo emite advertencias y errores.
Fuerza la descarga de cada gema.
Prefiere actualizar solo a la siguiente versión del parche.
Prefiere actualizar solo a la siguiente versión secundaria.
Prefiere actualizar a la siguiente versión principal (predeterminada).
No permitir que ninguna gema se actualice más allá del último --patch | --menor | --mayor.
Use el comportamiento de actualización conservador de la instalación del paquete y no permita que se actualicen las dependencias indirectas.
Si ejecuta bundle update --all, el paquete ignorará las gemas instaladas anteriormente y resolverá todas las dependencias nuevamente según las últimas versiones de todas las gemas disponibles en las fuentes.
Considere el siguiente Gemfile(5):
source "https://rubygems.org"
gem "rails", "3.0.0.rc"
gem "nokogiri"Cuando ejecutas bundle install(1) bundle-install.1.html por primera vez, bundler resolverá todas las dependencias, hasta abajo, e instalará lo que necesites:
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.Como puede ver, aunque tiene dos gemas en el Gemfile(5), su aplicación necesita 26 gemas diferentes para ejecutarse. Bundler recuerda las versiones exactas que instaló en Gemfile.lock. La próxima vez que ejecute bundle install(1) bundle-install.1.html, bundler omite la resolución de dependencia e instala las mismas gemas que instaló la última vez.
Después de registrar Gemfile.lock en el control de versiones y clonarlo en otra máquina, ejecutar bundle install(1) bundle-install.1.html todavía instale las gemas que instaló la última vez. No tienes que preocuparte de que una nueva versión de erubis o correo cambie las gemas que usas.
Sin embargo, de vez en cuando, es posible que desee actualizar las gemas que está utilizando a las versiones más recientes que aún coinciden con las gemas en su Gemfile(5).
Para hacer esto, ejecute bundle update --all, que ignorará el Gemfile.lock y resolverá todas las dependencias nuevamente. Tenga en cuenta que este proceso puede resultar en un conjunto significativamente diferente de las 25 gemas, según los requisitos de las nuevas gemas que los autores de las gemas lanzaron desde la última vez que ejecutó bundle update --all.
A veces, desea actualizar una sola gema en Gemfile(5) y dejar el resto de las gemas que especificó bloqueadas en las versiones en Gemfile.lock.
Por ejemplo, en el escenario anterior, imagina que nokogiri lanza la versión 1.4.4 y quieres actualizarla sin actualizar Rails y todo sus dependencias. Para ello, ejecuta bundle update nokogiri.
Bundler actualizará nokogiri y cualquiera de sus dependencias, pero dejará Rails y sus dependencias en paz.
A veces, varias gemas declaradas en su Gemfile(5) son satisfechas por la misma dependencia de segundo nivel. Por ejemplo, considere el caso de thin y rack-perftools-profiler.
source "https://rubygems.org"
gem "thin"
gem "rack-perftools-profiler"La gema delgada depende de rack >= 1.0, mientras que rack-perftools-profiler depende de rack ~> 1.0 . Si ejecuta la instalación del paquete, obtiene:
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)En este caso, las dos gemas tienen su propio conjunto de dependencias, pero comparten rack en común. Si ejecuta bundle update thin, bundler actualizará daemons, eventmachine y rack, que son dependencias de thin, pero no open4 o perftools.rb, que son dependencias de rack-perftools_profiler. Tenga en cuenta que bundle update thin actualizará rack aunque también depende de rack-perftools_profiler.
En resumen, de forma predeterminada, cuando actualiza una gema mediante actualización de paquete, el paquete actualizará todas las dependencias de esa gema, incluidas aquellas que también son dependencias de otra gema.
Para evitar la actualización de dependencias indirectas, antes de la versión 1.14, la única opción era el comportamiento de ACTUALIZACIÓN CONSERVADORA en bundle install(1) bundle-install.1.html:
En este escenario, actualizar la versión thin manualmente en Gemfile(5) y luego ejecutar bundle install(1) bundle-install.1.html solo actualizará daemons y eventmachine, pero no rack. Para obtener más información, consulte la sección ACTUALIZACIÓN CONSERVADORA de la instalación del paquete (1) bundle-install.1.html.
A partir de 1.14, especificar la opción --conservative también evitará que se actualicen las dependencias indirectas.
La versión 1.14 introdujo 4 opciones a nivel de parche que influirán en cómo se resuelven las versiones de gemas. Se puede utilizar una de las siguientes opciones: --patch, --minor o --major. Se puede agregar --strict para influir aún más en la resolución.
Prefiere actualizar solo a la siguiente versión del parche.
Prefiere actualizar solo a la siguiente versión secundaria.
Prefiere actualizar a la siguiente versión principal (predeterminada).
No permitir que ninguna gema se actualice más allá del último --patch | --menor | --mayor.
Cuando Bundler está resolviendo qué versiones usar para satisfacer los requisitos declarados en el Gemfile o en las gemas principales, busca todas las versiones disponibles, filtra las versiones que no satisfacen el requisito y luego, de forma predeterminada, las ordena de la más nueva a la más reciente. más antiguos, considerándolos en ese orden.
Proporcionar una de las opciones de nivel de parche (por ejemplo, --patch) cambia el orden de clasificación de las versiones satisfactorias, lo que hace que Bundler considere el último --patch o - -versión menor disponible antes que otras versiones. Tenga en cuenta que las versiones fuera del nivel de parche indicado aún podrían resolverse si es necesario para encontrar un gráfico de dependencia adecuado.
Por ejemplo, si la gema 'foo' está bloqueada en 1.0.2, sin ningún requisito de gema definido en el Gemfile, y existen las versiones 1.0.3, 1.0.4, 1.1.0, 1.1.1, 2.0.0, el valor predeterminado el orden de preferencia predeterminado (--principal) será "2.0.0, 1.1.1, 1.1.0, 1.0.4, 1.0.3, 1.0.2".
Si se utiliza la opción --patch, el orden de preferencia cambiará a "1.0.4, 1.0.3, 1.0.2, 1.1.1, 1.1.0, 2.0.0".
Si se usa la opción --minor, el orden de preferencia cambiará a "1.1.1, 1.1.0, 1.0.4, 1.0.3, 1.0.2, 2.0.0".
La combinación de la opción --strict con cualquiera de las opciones de nivel de parche eliminará cualquier versión que esté fuera del alcance de la opción de nivel de parche, para garantizar que ninguna gema se actualice tanto.
Para continuar con el ejemplo anterior, si se utilizan las opciones --patch y --strict, las versiones disponibles para la resolución serían "1.0.4, 1.0.3, 1.0 .2". Si se usan --minor y --strict, sería "1.1.1, 1.1.0, 1.0.4, 1.0.3, 1.0.2".
Los requisitos de gemas, tal como se definen en Gemfile, seguirán siendo el primer factor determinante de las versiones disponibles. Si el requisito de la gema para foo en el Gemfile es '~> 1.0', logrará lo mismo que proporcionar --minor y --strict opciones.
Dadas las siguientes especificaciones de la gema:
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.0Archivo de gemas:
gem 'foo'Gemfile.lock:
foo (1.4.3)
bar (~> 2.0)
bar (2.0.3)Casos:
# 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'En el caso 1, la barra se actualiza a 2.1.1, un aumento de versión menor, porque la dependencia de foo 1.4.5 lo requería.
En el caso 2, solo se solicita el desbloqueo de foo, pero también se permite mover la barra porque no es una dependencia declarada en el Gemfile.
En el caso 3, bar sube una versión principal completa, porque ahora se prefiere un aumento menor para foo, y cuando pasa a 1.5.1, requiere 3.0.0 de bar.
En el caso 4, se prefiere foo hasta una versión menor, pero la 1.5.1 no funcionará porque el indicador --strict quita la consideración de la barra 3.0.0 ya que es un incremento importante.
En el caso 5, tanto foo como bar tienen cualquier incremento mayor o menor eliminado debido a la bandera --strict, por lo que lo máximo que pueden mover es hasta 1.4.4 y 2.0.4.
En general, cuando trabaje con una aplicación administrada con bundler, debe usar el siguiente flujo de trabajo:
Después de crear su Gemfile(5) por primera vez, ejecute
bundle install
Compruebe el Gemfile.lock resultante en el control de versiones
git add Gemfile.lock
Al verificar este repositorio en otra máquina de desarrollo, ejecute
bundle install
Al verificar este repositorio en una máquina de implementación, ejecute
bundle install --deployment
Después de cambiar Gemfile(5) para reflejar una dependencia nueva o actualizada, ejecute
bundle install
Asegúrese de verificar el Gemfile.lock actualizado en el control de versiones
git add Gemfile.lock
Si bundle install(1) bundle-install.1.html informa un conflicto, actualice manualmente las gemas específicas que cambió en Gemfile(5)
bundle update rails thin
Si desea actualizar todas las gemas a las últimas versiones posibles que aún coincidan con las gemas enumeradas en Gemfile(5), ejecute
bundle update --all