Bundler: está intentando instalar en modo de implementación después de cambiar su Gemfile

Soy bastante nuevo en bundler y capistrano, y estoy tratando de usarlos juntos. Cuando intento implementar, recibo 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 al sistema que se queja, y no entiendo por qué surge la queja porque leí en el documento :

Si existe un Gemfile.lock y ha actualizado su Gemfile (5), el empaquetador usará las dependencias en 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.

Interpreto que eso 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 Posix.

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

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

El mensaje de error que está recibiendo en cuanto Gemfile.lockpuede ser porque su Gemfiley Gemfile.lockno están de acuerdo entre sí. Parece que ha cambiado algo en su Gemfile desde la última vez que ejecutó bundle install(o update). Cuando usted bundle install, actualiza su Gemfile.lock con cualquier cambio que haya realizado en Gemfile.

Asegúrese de ejecutar bundle installlocalmente y regístrese para controlar el código fuente de su nueva actualización Gemfile.lockdespués de eso. 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 indicador de plataforma para estas gemas dependientes de la plataforma en el Gemfile debería resolver la asimetría.

vi. paquete / config

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

hacer "instalación en paquete"

O

ejecutar "bundle config"

ver si el valor "congelado" es verdadero establecerlo en falso

configuración de paquete congelada falsa

Tenga cuidado con la configuración global de Bundler.

Tenía una configuración global en mi entorno de desarrollo ~/.bundle/configque no tenía en mi entorno de CI / Producción que provocó Gemfile.lockque el que se generó en mi entorno de desarrollo fuera diferente al de mi entorno de CI / Producción.

En mi caso, estaba configurando github.httpscomo verdadero en mi entorno de desarrollo pero no tenía tal configuración en mi entorno de CI / Producción. Esto provocó que los dos Gemfile.lockarchivos fueran diferentes.

Cuando vea 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, el problema es más probable que tenga archivos .gem desactualizados en su directorio de proveedor / caché.

Quizás, anteriormente corriste $bundle install --deployment que puso algunos archivos .gem "desactualizados" en la 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 le dicen exactamente qué hacer para solucionar el problema.

Mi problema específico estaba relacionado con lo informado por @JoshPinter, es decir, discrepancias de host entre dev-vs-deploy en el protocolo utilizado por el agrupador para recuperar gemas de github.

Para resumir, todo lo que tuve que hacer fue modificar la siguiente Gemfileentrada ...

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.

La solución para mí fue ligeramente diferente a las otras enumeradas aquí. Estaba intentando actualizar de sidekiq a sidekiq-pro (que requiere el paquete 1.7.12+), pero seguía 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 paquete.

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

before_install: - gem update bundler

Esto obligó a travis-ci a utilizar la última versión del paquete e hizo que desapareciera el mensaje de error.

No me importa Esto es lo que hice. Lo arregló.

rm -rf .bundle 
rm -rf Gemfile.lock
bundle install

rm -fr .bundle

Me arregló el problema.

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

bundle install --deployment 

y luego intente implementar. Esto hace algo así como instalar todas sus gemas en la carpeta del proveedor, lo cual creo que generalmente es bueno evitar ... pero probablemente funcionará. Mi aplicación solía comportarse así, mi solución era eliminar versiones exactas para descargar en mi Gemfile, y luego volver a agrupar y desplegar.

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

a

gem 'rails_admin'

O puede hacer lo que sugiere y sacar su proyecto del servidor de producción a una máquina local, agruparlo y luego volver a enviarlo a su servidor. Es posible que esta solución no sea 100% correcta, pero algo funcionó para mí ... solo pensé en compartir. Buena suerte

Otra causa del error:

Esto es un poco tonto, pero estoy seguro de que alguien más cometerá el mismo error.

Para Rails 4, Heroku agregó el gem rails_12factor. Si lo estaba usando antes de que lo agregaran, entonces tendrá estas dos gemas:

gem 'rails_log_stdout',  github: 'heroku/rails_log_stdout'
gem 'rails3_serve_static_assets', github: 'heroku/rails3_serve_static_assets'

Tienes que eliminarlos cuando agregas el nuevo. (están incluidos). Creo que puede salirse con la suya hasta que toque las líneas en su archivo de gemas, luego Heroku nota la duplicación y grita con el error anterior.

buena suerte con Rails 4.

En nuestro caso, estábamos usando una función que no estaba disponible en una versión anterior del paquete que se ejecutaba en nuestra máquina de producción. Por lo tanto, fue suficiente actualizar el paquete, es decir, hacer un gem update bundler.

Esta puede ser una idea peligrosa, pero si es absolutamente necesario probar algo en un entorno de implementación de producción, puede editar el archivo .bundle / config.

# This value is normally '1' 
# Set it to '0'
BUNDLE_FROZEN: '0'

Ahora invoque el paquete, en mi caso necesitaba actualizar una gema específica, así que este es mi comando

RAILS_ENV=production bundle update <whatever gem>

Probablemente debería volver a cambiarlo después de la actualización, para que las cosas funcionen como espera después. Nuevamente, esto probablemente no sea compatible y YMMV

Me encontré con esto implementando una aplicación Nesta después de algunas actualizaciones de gemas. Lo que funcionó para mí fue eliminar Gemfile.lock , ejecutarlo bundle installpara volver a generarlo e implementarlo nuevamente.

Me encontré con un problema similar, sin embargo, hice ambas bundle installybundle update y Heroku siendo rechazado mi empuje.

Solucioné el problema simplemente eliminando Gemfile.lock y luego ejecutándolo bundle installnuevamente. Luego agregué, comprometí y envié eso a mi repositorio de git. Después de eso, no tuve ningún problema en presionar a Heroku.

para heroku, no es necesario cambiar la sintaxis en Gemfile. simplemente puede agregar BUNDLE_GITHUB__HTTPS(tenga en cuenta el doble subrayado) como una variable de entorno y establecerla en true(en el panel de control de su aplicación heroku debajo de la Settingspestaña en la Config Varssección). esto cambiará el protocolo de git://a https://para todas esas solicitudes.

Recibí el mensaje de error al intentar enviar a Heroku. Encontré la siguiente solución arreglada.

1. Maestro de origen de extracción de Git
2. Estado de Git
3. Git commit
4. Maestro de origen de Git push
5. Git push heroku master

Este problema puede estar relacionado con submódulos que apuntan a versiones antiguas de código. Para mí, resolví este problema actualizando mis submódulos

Si tiene submódulos, intente ejecutar:

git submodule update --init

bundle install

Después de este comando, puede volver a realizar la instalación normal del paquete:

bundle install --no-deployment

Leí una docena de soluciones sobre diferentes recursos pero no encontré exactamente qué podría ayudarme en esta situación.

Entonces encontré una solución. Diciendo exactamente que leí el mensaje de error con atención y hubo una solución: Ejecute la instalación del paquete en otro lugar . "Elsewhere" fue mi Cloud9 donde desarrollé mi aplicación. Entonces mis pasos

1. copie Gemfile y Gemfile.lock del servidor a la máquina local con rsync comando
2. inserte estos dos archivos en mi proyecto RoR (usé Cloud9)
3. abra Gemfile y realice los cambios que desee. En mi caso agregué gema 'delgada'
4. en el cd de la terminal a mi aplicación en Cloud9 y ejecutar bundle install. en este caso, tendrá una versión modificada de Gemfile.lock
5. copie el nuevo Gemfile y Gemfile.lock en el servidor usandorsync
6. cd a la carpeta de mi aplicación y vuelva a ejecutar bundle install --deployment --without development test DONE! ¡Deseamos BUENA suerte para todos!