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

86

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
JellicleCat
fuente

Respuestas:

80

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.

Edd Morgan
fuente
2
Suena como la respuesta correcta, pero ejecuté bundle install en mi máquina de desarrollo, luego verifiqué tanto el Gemfile como su bloqueo en svn, luego usé capistrano. ¿Podría el problema deberse a que el Gemfile incluye un bloque con unless RbConfig::CONFIG['host_os'] === 'mingw32':? (Ergo, debería agrupar elementos diferentes en mi computadora con Windows que en el servidor Linux).
JellicleCat
1
Muy posiblemente. Verifique el contenido de su Gemfile.lock: ¿contiene referencias de gemas que solo deberían incluirse en Windows? Si es así, eso sugeriría que en la máquina de implementación, Gemfile y Gemfile.lock difieren. (Además, no soy un experto en Bundler, pero estoy bastante seguro de que poner condicionales en su Gemfile no es la mejor práctica. Considere usar grupos o el indicador de plataforma:) .
Edd Morgan
2
El uso de la :platformsbandera para las gemas que necesitaba mi servidor prod (posix) pero que no estaban en mi servidor dev (win) hizo la diferencia: platforms :ruby do; gem 'mygem'; ...; end(Obtiene la marca verde si no le importaría agregar esta instrucción a su respuesta)
JellicleCat
: la plataforma no puede distinguir entre el uso de Linux y / o darwin env :require, también funciona bien stackoverflow.com/a/16475580/933358
Daniël W. Crompton
¡Esto funcionó para mí! ¡Gracias, me salvó de más días de frustración!
thenextmogul
26

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

Gaurav24
fuente
Esto es lo que hizo por mí. Curiosamente, en el archivo de configuración en sí, la clave BUNDLE_FROZEN no se estableció en absoluto. Me pregunto, ¿es posible que haya configurado BUNDLE_FROZEN: 1 en otro lugar?
Bo G.
bundle config frozen falsees mi goto arreglar. ¡Muchas gracias, dos años después! Creo que la respuesta de Joshua Pinter aborda el comentario anterior: puede ser la configuración global de Bundler lo que afecta esto.
SRack el
bundle config frozen falseno hizo nada por mí. Se recurrió a editar .bundle / config en el que la entrada BUNDLE_FROZEN = "true" (textual true)
Arthur
19

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.

Joshua Pinter
fuente
2
¡Gracias! de todas las respuestas simples relacionadas con este ridículo error, esto es lo que me hizo volver al trabajo. ¿Por qué diablos Heroku no ayuda automáticamente con esto? ¡Qué mala razón para haber perdido las últimas 3 horas de mi vida!
Hellion
2
Puede que me hayas salvado la vida. Me estaba preparando para dispararme por esto: P
Tyrone Wilson
1
@JoshuaPinter, sí, ¡esto me salvó! aunque con pasar varias horas en él ... pero estaba tratando de corregir las advertencias que recibía cuando hacía 'instalación de paquete' y me quedé atrapado en este lío. ¡Muy apreciado!
daveomcd
1
@daveomcd Estuve allí, me alegro de que te haya ahorrado varias horas más de rascarte la cabeza. :)
Joshua Pinter
11

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.

l3x
fuente
7

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.

Giuseppe
fuente
Esto también solucionó el problema para mí. Muy extraño.
Joshua Muheim
6

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.

dacoinminster
fuente
Esto funcionó para mí bajo Capistrano para ejecutar cap shelly gem update bundlero with <role> gem update bundleroon <machine> gem update bundler
Eric
4

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

rm -rf .bundle 
rm -rf Gemfile.lock
bundle install
William Entriken
fuente
3
rm -fr .bundle

Me arregló el problema.

Aneil Mallavarapu
fuente
1

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

Multitud
fuente
1
La --deploymentbandera no hizo una diferencia a menos que borrara Gemfile.lock. ¿Es así como se supone que debe ser?
JellicleCat
1

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.

bobbdelsol
fuente
1

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.

nerdinand
fuente
Gracias, yo también tuve este problema. Resultó que la versión del paquete en el servidor era más antigua que la que usábamos en nuestros escritorios.
Nathan Bertram
1

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

Chewbarkla
fuente
0

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.

Yarin
fuente
0

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.

Ryan Rich
fuente
A menos que haya arreglado sus versiones de gemas en su archivo de gemas, esto es arriesgado ... podría actualizar gemas y romper su aplicación
Abram
0

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.

clarividencia
fuente
0

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
Ben Strachan
fuente
0

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

Gerard Simpson
fuente
0

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

bundle install --no-deployment
ServerElf
fuente
0

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!
Vitaliy LiBrus
fuente