Pregunta Bundler: Estás intentando instalar en modo de implementación después de cambiar tu Gemfile


Soy bastante nuevo para bundler y capistrano, y estoy tratando de usarlos juntos. Cuando intento implementar, obtengo el mensaje:

Está intentando instalar en modo de implementación después de cambiar su Gemfile. Ejecute `bundle install 'en otro lugar y agregue el Gemfile.lock actualizado al control de versiones.

No sé cómo satisfacer el sistema que se queja, y no entiendo por qué está surgiendo la queja porque leí en El documento:

Si existe un Gemfile.lock y ha actualizado su Gemfile (5),   bundler usará las dependencias en Gemfile.lock para todas las gemas   que no actualizaste, pero volverá a resolver las dependencias de las gemas   que has actualizado Puede encontrar más información sobre esta actualización   proceso debajo bajo ACTUALIZACIÓN CONSERVADORA.

Lo interpreto como que significa que el Bundler puede manejar el hecho de que mi Gemfile no es lo que esperaba. ¿Alguna ayuda?

Especificaciones: Ruby 1.9.3, Rails 3.2.3, Capistrano 2.12.0, Bundler 1.1.4, Windows 7, implementación en una máquina de Posix.

Editar: My Gemfile incluye bloques lógicos como los siguientes:

unless RbConfig::CONFIG['host_os'] === 'mingw32'
  # gem 'a' ...
end

74
2017-07-16 22:39


origen


Respuestas:


El mensaje de error que recibes con respecto a Gemfile.lock puede ser porque tu Gemfile y Gemfile.lock no estoy de acuerdo el uno con el otro Parece que ha cambiado algo en su Gemfile desde la última vez que ejecutó bundle install (o update) Cuando tú bundle install, actualiza tu Gemfile.lock con cualquier cambio que hayas hecho en Gemfile.

Asegúrate de correr bundle install localmente, y check-in para controlar la fuente de su recién actualizado Gemfile.lock después de esto. Luego intente implementar.

Editar: Como se reconoce en los comentarios, un condicional en el Gemfile resultó en un Gemfile.lock válido en una plataforma, inválido en otra. Proporcionar un :plataforma la bandera de estas gemas dependientes de la plataforma en el Gemfile debería resolver la asimetría.


67
2017-07-16 23:04



vi. paquete / config

cambie la opción BUNDLE_FROZEN de '1' a '0'

hacer "paquete de instalación"


O

ejecutar "bundle config"

ver si el valor "congelado" es verdadero, establézcalo en falso

paquete config congelado falso


21
2018-05-23 12:00



Tenga cuidado con la configuración global de Bundler.

Tenía una configuración global en mi entorno de desarrollo en ~/.bundle/config que no tenía en mi entorno de CI / Producción que causó la Gemfile.lock que se generó en mi entorno de desarrollo para ser diferente al que está en mi entorno de CI / Producción.

En mi caso yo estaba arreglando github.https verdadero en mi entorno de desarrollo, pero no tenía esa configuración en mi entorno de producción / CI. Esto causó los dos Gemfile.lock archivos para ser diferente.


16
2017-11-12 21:46



Cuando ves lo siguiente ...

$ bundle install
You are trying to install in deployment mode after changing
your Gemfile. Run `bundle install` elsewhere and add the
updated Gemfile.lock to version control.

If this is a development machine, remove the Gemfile freeze
by running `bundle install --no-deployment`.

You have added to the Gemfile:
* source: rubygems repository https://rubygems.org/
* rails (~> 3.2)
. . .

... Entonces, es muy probable que tenga archivos .gem obsoletos en su directorio de proveedor / caché.

Quizás, anteriormente corrió $bundle install --deployment que puso algunos archivos .gem "desactualizados" en el caché?

En cualquier caso, puede superar este error ejecutando: bundle install --no-deployment

Esa es una de las muchas cosas buenas de Rails ... los mensajes de error a menudo te dicen exactamente qué hacer para solucionar el problema.


9
2018-05-24 22:17



La solución para mí fue ligeramente diferente a las otras enumeradas aquí. Estaba tratando de actualizar de sidekiq a sidekiq-pro (que requiere bundler 1.7.12+), pero seguí recibiendo el mensaje "Estás intentando instalar en modo de implementación después de cambiar tu Gemfile" de travis-ci

La inspección de la salida de la consola de travis-ci reveló que se estaba utilizando una versión anterior del bundler.

En mi caso, tuve que editar el archivo travis.yml para agregar:

before_install: - gem update bundler

Esto obligó a Travis-ci a usar la última versión de bundler e hizo desaparecer el mensaje de error.


4
2017-09-25 19:02



rm -fr .bundle

Solucionado el problema para mí.


3
2017-10-25 21:33



Mi problema específico estaba relacionado con lo reportado por @JoshPinter, es decir, las discrepancias del host dev-vs-deploy en el protocolo utilizado por bundler para recuperar gems de github.

Para resumir, todo lo que tenía que hacer era modificar lo siguiente Gemfile entrada...

gem 'activeadmin', github: 'activeadmin'

... a esta sintaxis segura (ver referencia)

gem 'activeadmin', git: 'https://github.com/activeadmin/activeadmin.git'

Y mis despliegues han vuelto a la normalidad.


3
2017-12-22 08:39



Me encontré con algo similar antes. Una forma de solucionarlo, creo, pero puede llevar más espacio del que desea, es ejecutar

bundle install --deployment 

y luego intenta desplegar. Esto hace algo así como instalar todas sus gemas en la carpeta del proveedor, lo que creo que en general es bueno evitar ... pero probablemente todavía funcione. Mi aplicación solía comportarse así, mi solución consistía en eliminar las versiones exactas para descargarlas en mi Gemfile, y luego reinsertarlas e implementarlas.

gem 'rails_admin', :git => 'git://github.com/sferik/rails_admin.git', :branch => 'master'

a

gem 'rails_admin'

O puede hacer lo que sugiere, y llevar su proyecto fuera del servidor de producción a una máquina local, agruparlo y luego volver a instalarlo en su servidor. Esta solución puede no ser 100% correcta, pero algunas me funcionaron ... solo pensé en compartirla. Buena suerte


1
2017-07-16 22:52