bundle-install - Instala las dependencias especificadas en tu Gemfile
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...]]
Instale las gemas especificadas en su Gemfile(5). Si es la primera vez que ejecuta la instalación del paquete (y no existe un Gemfile.lock), Bundler buscará todas las fuentes remotas, resolverá las dependencias e instalará todas las gemas necesarias.
Si existe un Gemfile.lock y no ha actualizado su Gemfile(5), Bundler buscará todas las fuentes remotas, pero usará las dependencias especificadas en el Gemfile.lock en lugar de resolver dependencias.
Si existe un Gemfile.lock y ha actualizado su Gemfile(5), Bundler usará las dependencias en el Gemfile.lock para todas las gemas que no actualizó , pero volverá a resolver las dependencias de las gemas que actualizó. Puede encontrar más información sobre este proceso de actualización a continuación en ACTUALIZACIÓN CONSERVADORA.
El --limpio, --despliegue, --congelado, --no-prune, --path, --shebang, --system, --sin y --with Las opciones están en desuso porque solo tienen sentido si se aplican a cada instalación de paquete subsiguiente que se ejecuta automáticamente y eso requiere que bundler las recuerde en silencio. Dado que bundler ya no recordará los indicadores de CLI en versiones futuras, se debe usar bundle config (consulte bundle-config(1)) para aplicarlos de forma permanente.
Los binstubs son scripts que envuelven ejecutables. Bundler crea un pequeño archivo Ruby (un binstub) que carga Bundler, ejecuta el comando y lo coloca en bin/. Esto le permite vincular el binstub dentro de una aplicación a la versión gema exacta que necesita la aplicación.
Crea un directorio (predeterminado en ~/bin) y coloca allí los archivos ejecutables de la gema. Estos ejecutables se ejecutan en el contexto de Bundler. Si se usa, puede agregar este directorio a la variable PATH de su entorno. Por ejemplo, si la gema rails viene con un ejecutable rails, esta marca creará un ejecutable bin/rails que garantiza que todas las dependencias referidas resolverse usando las gemas incluidas.
Al finalizar la instalación, Bundler eliminará cualquier gema que no esté presente en el Gemfile(5) actual. No te preocupes, las gemas actualmente en uso no se eliminarán.
Esta opción está obsoleta en favor de la configuración limpia.
En modo de implementación, Bundler 'implementará' el paquete para producción o uso de CI. Verifique cuidadosamente si desea tener esta opción habilitada en su entorno de desarrollo.
Esta opción está obsoleta en favor de la configuración de implementación.
Fuerce la descarga de cada gema, incluso si las versiones requeridas ya están disponibles localmente.
No permita que Gemfile.lock se actualice después de esta instalación. Sale distinto de cero si va a haber cambios en Gemfile.lock.
Esta opción está obsoleta en favor de la configuración congelada.
Bundler no llamará al punto final de la API de Rubygems (predeterminado), sino que descargará y almacenará en caché un archivo de índice (actualmente grande) de todas las gemas. El rendimiento se puede mejorar para paquetes grandes que rara vez cambian al habilitar esta opción.
La ubicación del Gemfile(5) que debe usar Bundler. Esto por defecto es un Gemfile(5) en el directorio de trabajo actual. En general, Bundler supondrá que la ubicación de Gemfile(5) también es la raíz del proyecto e intentará encontrar Gemfile.lock y vendor/cache en relación con esta ubicación. .
El número máximo de trabajos paralelos de descarga e instalación. El valor predeterminado es el número de procesadores disponibles.
No intente conectarse a rubygems.org. En su lugar, Bundler usará las gemas que ya están presentes en el caché de Rubygems o en proveedor/caché. Tenga en cuenta que si existe una gema específica de plataforma adecuada en rubygems.org, no se encontrará.
Fuerce el uso de gemas instaladas localmente, o gemas que ya están presentes en el caché de Rubygems o en proveedor/caché, al resolver, incluso si hay versiones más nuevas disponibles de forma remota. Solo intente conectarse a rubygems.org para las gemas que no están presentes localmente.
No actualices el caché en proveedor/caché con las gemas recién agrupadas. Esto no elimina ninguna gema en el caché, pero evita que las gemas recién agrupadas se almacenen en caché durante la instalación.
No elimine las gemas obsoletas del caché cuando finalice la instalación.
Esta opción está obsoleta en favor de la configuración no_prune.
La ubicación para instalar las gemas especificadas. Esto por defecto es la configuración de Rubygems. Bundler comparte esta ubicación con Rubygems, gem install ... también tendrá gema instalada allí. Por lo tanto, las gemas instaladas sin una configuración de --path ... aparecerán llamando a gem list. En consecuencia, las gemas instaladas en otras ubicaciones no aparecerán en la lista.
Esta opción está obsoleta en favor de la configuración de ruta.
No imprima información de progreso en la salida estándar. En su lugar, Bundler saldrá usando un código de estado ($?).
Vuelva a intentar las solicitudes fallidas de red o git por número veces.
Utiliza el ejecutable de ruby especificado (generalmente ruby) para ejecutar los scripts creados con --binstubs. Además, si usa --binstubs junto con --shebang jruby, estos ejecutables se cambiarán para ejecutar jruby en su lugar.
Esta opción está obsoleta en favor de la configuración shebang.
Crea un paquete que puede funcionar sin depender de Rubygems o Bundler en tiempo de ejecución. Se debe especificar una lista de grupos separados por espacios para instalar. Bundler crea un directorio llamado bundle e instala el paquete allí. También genera un archivo bundle/bundler/setup.rb para reemplazar la configuración propia de Bundler de la manera requerida. El uso de esta opción establece implícitamente ruta, que es una [opción recordada][OPCIONES RECORDADAS].
Instala las gemas especificadas en el paquete en la ubicación de Rubygems del sistema. Esto anula cualquier configuración anterior de --path.
Esta opción está en desuso en favor de la configuración sistema.
Aplique la política de seguridad de Rubygems política, donde la política es una de HighSecurity, MediumSecurity, LowSecurity, AlmostNoSecurity o Sin seguridad. Para obtener más detalles, consulte la documentación de firma de Rubygems vinculada a continuación en VER TAMBIÉN.
Una lista separada por espacios de grupos que hacen referencia a gemas para instalar. Si se proporciona un grupo opcional, se instala. Si se da un grupo que está en la lista recordada de grupos dados a --sin, se elimina de esa lista.
Esta opción está en desuso en favor de la configuración con.
Una lista separada por espacios de grupos que hacen referencia a gemas para omitir durante la instalación. Si se da un grupo que está en la lista recordada de grupos dada a --with, se elimina de esa lista.
Esta opción está obsoleta en favor de la configuración sin.
Los valores predeterminados de Bundler están optimizados para el desarrollo. Para cambiar a los valores predeterminados optimizados para implementación y CI, use el indicador --deployment. No active el modo de implementación en las máquinas de desarrollo, ya que provocará un error cuando se modifique el Gemfile(5).
Se requiere un Gemfile.lock. Para asegurarse de que las mismas versiones de las gemas con las que desarrolló y probó también se usan en las implementaciones, se requiere un Gemfile.lock. Esto es principalmente para asegurarse de que recuerde verificar su Gemfile.lock en el control de versiones.
El Gemfile.lock debe estar actualizado En desarrollo, puede modificar su Gemfile(5) y volver a ejecutar la instalación del paquete para actualizar de manera conservadora su instantánea Gemfile.lock. En la implementación, su Gemfile.lock debe estar actualizado con los cambios realizados en su Gemfile(5).
Las gemas se instalan en proveedor/paquete, no en la ubicación predeterminada de su sistema En desarrollo, es conveniente compartir las gemas utilizadas en su aplicación con otras aplicaciones y otros scripts que se ejecutan en el sistema. En la implementación, el aislamiento es un valor predeterminado más importante. Además, es posible que el usuario que implementa la aplicación no tenga permiso para instalar gemas en el sistema, o que el servidor web no tenga permiso para leerlas. Como resultado, bundle install --deployment instala gemas en el directorio vendor/bundle de la aplicación. Esto se puede anular utilizando la opción --path.
De forma predeterminada, la instalación de paquete instalará todas las gemas en todos los grupos en su Gemfile(5), excepto aquellas declaradas para una plataforma diferente.
Sin embargo, puede decirle explícitamente a Bundler que omita la instalación de ciertos grupos con la opción --sin. Esta opción toma una lista de grupos separados por espacios.
Si bien la opción --sin omitirá la instalación de las gemas en los grupos especificados, seguirá descargando esas gemas y las usará para resolver las dependencias. de cada gema en su Gemfile(5).
Esto es para que la instalación de un conjunto diferente de grupos en otra máquina (como un servidor de producción) no cambie las gemas y las versiones que ya ha desarrollado y probado.
Bundler ofrece una garantía sólida de que el código de terceros que está ejecutando en desarrollo y prueba también es el código de terceros que está ejecutando en producción. Puede optar por excluir parte de ese código en diferentes entornos, pero nunca se verá sorprendido por las diferentes versiones de código de terceros que se utilizan en diferentes entornos.
Para una ilustración simple, considere el siguiente Gemfile(5):
source 'https://rubygems.org'
gem 'sinatra'
group :production do
gem 'rack-perftools-profiler'
endEn este caso, sinatra depende de cualquier versión de Rack (>= 1.0), mientras que rack-perftools-profiler depende de 1.x ( ~> 1.0).
Cuando ejecuta instalación de paquete --sin producción en desarrollo, también observamos las dependencias de rack-perftools-profiler. De esa manera, no perderá todo su tiempo desarrollando contra Rack 2.0, usando API nuevas que no están disponibles en Rack 1.x, solo para que Bundler cambie a Rack 1.2 cuando el grupo de producción es usado.
Esto no debería causar ningún problema en la práctica, porque no intentamos instalar las gemas en los grupos excluidos y solo las evaluamos como parte del proceso de resolución de dependencias.
Esto también significa que no puede incluir diferentes versiones de la misma gema en diferentes grupos, ya que, al hacerlo, se utilizarían diferentes conjuntos de dependencias en el desarrollo y la producción. Debido a los caprichos del proceso de resolución de dependencias, esto generalmente afecta más que las gemas que enumera en su Gemfile(5) y puede (sorprendentemente) cambiar radicalmente las gemas que está utilizando.
Cuando ejecuta instalación de paquete, Bundler conservará los nombres completos y las versiones de todas las gemas que utilizó (incluidas las dependencias de las gemas especificadas en Gemfile(5)) en un archivo llamado Gemfile. bloquear.
Bundler usa este archivo en todas las llamadas subsiguientes a bundle install, lo que garantiza que siempre use exactamente el mismo código, incluso cuando su aplicación se mueve entre máquinas.
Debido a la forma en que funciona la resolución de dependencias, incluso un cambio aparentemente pequeño (por ejemplo, una actualización de un lanzamiento puntual de una dependencia de una gema en su Gemfile(5)) puede hacer que se necesiten gemas radicalmente diferentes para satisfacer todas las dependencias.
Como resultado, DEBE verificar su Gemfile.lock en el control de versiones, tanto en aplicaciones como en gemas. Si no lo hace, cada máquina que verifica su repositorio (incluido su servidor de producción) resolverá todas las dependencias nuevamente, lo que resultará en el uso de diferentes versiones de código de terceros si cualquiera de las gemas en el Gemfile(5) o cualquiera de sus dependencias han sido actualizados.
Cuando se envió Bundler por primera vez, el Gemfile.lock se incluyó en el archivo .gitignore incluido con las gemas generadas. Con el tiempo, sin embargo, quedó claro que esta práctica impone el dolor de las dependencias rotas a los nuevos colaboradores, mientras que deja a los colaboradores existentes potencialmente inconscientes del problema. Dado que la instalación del paquete suele ser el primer paso hacia una contribución, el dolor de las dependencias rotas desanimaría a los nuevos contribuyentes a contribuir. Como resultado, hemos revisado nuestra guía para los autores de gemas para recomendar ahora revisar el candado en busca de gemas.
Cuando realiza un cambio en Gemfile(5) y luego ejecuta instalación de paquete, Bundler actualizará solo las gemas que modificó.
En otras palabras, si una gema que no modificó funcionó antes de llamar a instalación de paquete, seguirá usando exactamente las mismas versiones de todas las dependencias que usaba antes de la actualizar.
Echemos un vistazo a un ejemplo. Aquí está su Gemfile original(5):
source 'https://rubygems.org'
gem 'actionpack', '2.3.8'
gem 'activemerchant'En este caso, tanto actionpack como activemerchant dependen de activesupport. La gema actionpack depende de activesupport 2.3.8 y rack ~> 1.1.0, mientras que la gema activemerchant depende en activesupport >= 2.3.2, braintree >= 2.0.0 y builder >= 2.0.0.
Cuando las dependencias se resuelvan por primera vez, Bundler seleccionará activesupport 2.3.8, que cumple con los requisitos de ambas gemas en su Gemfile(5).
A continuación, modifica su Gemfile(5) para:
source 'https://rubygems.org'
gem 'actionpack', '3.0.0.rc'
gem 'activemerchant'La gema actionpack 3.0.0.rc tiene varias dependencias nuevas y actualiza la dependencia activesupport a = 3.0.0.rc y la Dependencia de rack a ~> 1.2.1.
Cuando ejecuta instalación de paquete, Bundler nota que cambió la gema actionpack, pero no la gema activemerchant. Evalúa las gemas que se utilizan actualmente para satisfacer sus requisitos:
también se usa para satisfacer una dependencia en activemerchant, que no se actualiza
no se utiliza actualmente para satisfacer otra dependencia
Debido a que no solicitó explícitamente actualizar activemerchant, no esperaría que dejara de funcionar repentinamente después de actualizar actionpack. Sin embargo, satisfacer la nueva dependencia activesupport 3.0.0.rc de actionpack requiere actualizar una de sus dependencias.
Aunque activemerchant declara una dependencia muy flexible que teóricamente coincide con activesupport 3.0.0.rc, Bundler trata las gemas en su Gemfile(5) que no han cambiado como una unidad atómica. con sus dependencias. En este caso, la dependencia de activemerchant se trata como activemerchant 1.7.1 + activesupport 2.3.8, por lo que bundle install informará que no se puede actualizar paquete de acción.
Para actualizar explícitamente actionpack, incluidas sus dependencias de las que aún dependen otras gemas en Gemfile(5), ejecute bundle update actionpack (consulte bundle update(1) ).
Resumen: en general, después de realizar un cambio en Gemfile(5), primero debe intentar ejecutar instalación de paquete, lo que garantizará que no haya ninguna otra gema en Gemfile( 5) se ve afectado por el cambio. Si eso no funciona, ejecute la actualización del paquete (1) bundle-update.1.html.
Documentos de instalación de gemas http://guides.rubygems.org/rubygems-basics/#installing-gems
Documentos de firma de Rubygems http://guides.rubygems.org/security/