Bundler: You are trying to install in deployment mode after changing your Gemfile

Question

I'm pretty new to bundler and capistrano, and I'm trying to use them together. When I try to deploy, I get the message:

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.

I don't know how to satisfy the system that's complaining, and I don't understand why the complaint is coming up because I read in the doc:

If a Gemfile.lock does exist, and you have updated your Gemfile(5), bundler will use the dependencies in the Gemfile.lock for all gems that you did not update, but will re-resolve the dependencies of gems that you did update. You can find more information about this update process below under CONSERVATIVE UPDATING.

I interpret that to mean that the Bundler can handle the fact that my Gemfile is not whatever it expected. Any help?

Specs: Ruby 1.9.3, Rails 3.2.3, Capistrano 2.12.0, Bundler 1.1.4, Windows 7, deploying to a Posix machine.

Edit: My Gemfile includes logic blocks like the following:

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

score 89 · Accepted Answer · edited Jun 13 '16 at 22:31

89

The error message you're getting regarding Gemfile.lock may be because your Gemfile and Gemfile.lock don't agree with each other. It sounds like you've changed something in your Gemfile since you last ran bundle install (or update). When you bundle install, it updates your Gemfile.lock with any changes you've made to Gemfile.

Make sure you run bundle install locally, and check-in to source control your newly updated Gemfile.lock after that. Then try deploying.

Edit: As recognised in the comments, a conditional in the Gemfile resulted in a valid Gemfile.lock on one platform, invalid on another. Providing a :platform flag for these platform-dependent gems in the Gemfile should solve the asymmetry.

edited Jun 13 '16 at 22:31

Kick Buttowski

6,709
13
37
58

answered Jul 16 '12 at 23:04

Edd Morgan

2,873
17
22

2

Sounds like the right answer, but I did run bundle install on my dev machine, then checked both the Gemfile and its lock into svn, then used capistrano. Could the problem be because the Gemfile includes a block with: `unless RbConfig::CONFIG['host_os'] === 'mingw32'`? (Ergo it should bundle different items on my windows computer than on the linux server.) – JellicleCat Jul 16 '12 at 23:08
1

Quite possibly. Check the contents of your Gemfile.lock - does it contain references gem(s) that should only be included on Windows? If so, that would suggest that on the deployment machine, Gemfile and Gemfile.lock differ. (Also, I'm no Bundler expert, but I'm pretty sure putting conditionals in your Gemfile isn't best practice. Consider using [groups](http://gembundler.com/groups.html) or the [:platform flag](http://gembundler.com/man/gemfile.5.html#PLATFORMS-platforms-)). – Edd Morgan Jul 16 '12 at 23:15
2

Using the `:platforms` flag for the gems which my prod (posix) server needed but which were not on my dev (win) server made the difference: `platforms :ruby do; gem 'mygem'; ...; end` (You get the green check if you wouldn't mind adding this instruction to your answer.) – JellicleCat Jul 16 '12 at 23:38
:platform isn't able to distinguish between _linux_ and/or _darwin_ env using `:require`, works well too http://stackoverflow.com/a/16475580/933358 – Daniël W. Crompton Jan 12 '14 at 01:13
This was helpful! along with that, I also had to commit the vendor/cache - example. 'vendor/cache/mygem-0.1.0.gem' to fix this issue. – Rishi Feb 02 '16 at 18:09
Does anyone else have a nice history of commit messages right up until you setup capistrano and after that it's git commit -m'tried something else to fix capistrano deployment again' – Samuel Danielson Mar 08 '18 at 21:05

score 29 · Answer 2 · edited Apr 03 '23 at 13:37

29

vi .bundle/config

change the BUNDLE_FROZEN option from '1' to '0'

bundle install

bundle config

see if the "frozen" value is true set it to false

bundle config frozen false

edited Apr 03 '23 at 13:37

Hille

2,123
22
39

answered May 23 '15 at 12:00

Gaurav Ingalkar

1,217
11
20

This is what did it for me. Interestingly, in the config file itself, the key BUNDLE_FROZEN wasn't set at all. I wonder, is it possible that I had set BUNDLE_FROZEN: 1 elsewhere? – Bo G. Jan 16 '17 at 20:31
`bundle config frozen false` is my goto fix. Thanks very much, two years on! I believe Joshua Pinter's answer addresses the comment above - it can be the global Bundler config impacting this. – SRack Aug 15 '17 at 14:21
`bundle config frozen false` did nothing for me. Resorted to editing .bundle/config in which the entry BUNDLE_FROZEN = "true" (textual true) – Arthur Nov 14 '17 at 01:09
Note that you probably want frozen true, if this is running on CI or deployment. – Joao Cunha May 09 '22 at 17:51

Joshua Pinter · Answer 3 · 2017-02-16T23:35:46.170

21

Watch out for global Bundler config.

I had a global config on my dev environment in ~/.bundle/config that I did not have in my CI / Production environment that caused the Gemfile.lock that was generated in my dev environment to be different than the one in my CI / Production environment.

In my case I was setting github.https to true in my dev environment but had no such config in my CI / Production environment. This caused the two Gemfile.lock files to be different.

edited Feb 16 '17 at 23:35

answered Nov 12 '16 at 21:46

Joshua Pinter

45,245
23
243
245

2

thanks! of all the simple answers flying around related to this ridiculous error---this is what got me back to work. Why the hell does Heroku not auto-assist with this? What a lame reason to have lost the last 3 hours of my life! – hellion Dec 02 '16 at 00:23
2

You may just have saved my life. I was getting ready to shoot myself over this :P – Tyrone Wilson Feb 16 '17 at 11:44
1

@JoshuaPinter, yes this saved me! albeit with spending several hours on it... but I was trying to correct the warnings I was getting when doing 'bundle install' and got stuck in this pickle. Much appreciated! – daveomcd Aug 25 '17 at 20:37
1

@daveomcd Been there, glad it saved you another several hours of scratching your head. :) – Joshua Pinter Aug 25 '17 at 22:53

l3x · Answer 4 · 2013-05-24T22:26:43.450

When you see the following...

$ 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)
. . .

... Then, the problem is most likely that you have outdated .gem files in your vendor/cache directory.

Perhaps, you previously ran $bundle install --deployment which put some "outdated" .gem files in the cache?

In any case, you can get past this error by running: bundle install --no-deployment

That's one of the many great things about Rails... the error messages often tell you exactly what to do to fix the problem.

score 11 · Answer 5 · answered Dec 22 '16 at 08:39

11

My specific problem was related to what reported by @JoshPinter, i.e. dev-vs-deploy host discrepancies in the protocol used by bundler to retrieve gems from github.

To make a long story short, all I had to was modify the following Gemfile entry...

gem 'activeadmin', github: 'activeadmin'

...to this secure syntax (see reference):

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

And my deployments are back to normal.

answered Dec 22 '16 at 08:39

Giuseppe

5,188
4
40
37

1

This fixed the problem for me, too. Really strange. – Joshua Muheim Sep 16 '19 at 06:16
I was working on an old code-base. I ran into this issue after upgrading ruby version. This fixed the problem. – Agent47DarkSoul Feb 11 '21 at 18:14

score 8 · Answer 6 · answered Oct 03 '19 at 18:58

8

I don't care. This is what I did. It fixed it.

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

answered Oct 03 '19 at 18:58

William Entriken

37,208
23
149
195

yup... that's what i did too. Also added the bundle lock --add-platform x86_64-linux afterwards and it worked – Filippos Apr 28 '22 at 15:36

score 7 · Answer 7 · answered Sep 25 '15 at 19:02

7

The solution for me was slightly different than the others listed here. I was trying to upgrade from sidekiq to sidekiq-pro (which requires bundler 1.7.12+), but I kept getting the "You are trying to install in deployment mode after changing your Gemfile" message from travis-ci

Inspecting the console output of travis-ci revealed that an older version of bundler was being used.

In my case, I had to edit the travis.yml file to add:

before_install: - gem update bundler

This forced travis-ci to use the latest version of bundler, and made the error message go away.

answered Sep 25 '15 at 19:02

dacoinminster

3,637
2
18
23

This worked for me under Capistrano to run `cap shell` and `gem update bundler` or `with gem update bundler` or `on gem update bundler` – Eric Mar 23 '16 at 23:22
Same here. In Jenkins, we were using bundler v2.2.9, and locally I was using v2.2.25. Updating the the bundler version in Jenkins solved the problem...probably. I also resolved several bundler deprecation warnings, such as, "The `--deployment` flag is deprecated because it relies on being remembered across bundler invocations, which bundler will no longer do in future versions.", so maybe that had some effect as well. – David Hempy Aug 13 '21 at 15:04

score 3 · Answer 8 · answered Oct 25 '16 at 21:33

3

rm -fr .bundle

Fixed the problem for me.

answered Oct 25 '16 at 21:33

Aneil Mallavarapu

3,485
5
37
41

score 2 · Answer 9 · edited Jan 02 '14 at 08:29

Another cause of the error:

This is a bit foolish, but i'm sure someone else will make the same mistake.

For Rails 4 Heroku added the gem rails_12factor. If you were using it before they added it, then you'll have these two gems:

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

You have to remove them when you add the new one. (they're included). I think you can get away with it until you touch them lines in your gem file, then Heroku notices the duplication and cries out with the above error.

good luck with Rails 4.

score 2 · Answer 10 · answered Dec 11 '18 at 23:35

2

After this command, you can do your normal bundle install again:

bundle install --no-deployment

answered Dec 11 '18 at 23:35

ServerElf

21
1

2

if this is a capistrano deployment, use `set :bundle_config, { deployment: false }` – simo Dec 31 '21 at 11:54
Thanks! This is the only thing that worked for me, after I updated ruby version in deployment machine and bundle install via capistrano stopped working. – Augusto Samamé Barrientos Feb 16 '22 at 20:58

score 1 · Answer 11 · answered Jul 16 '12 at 22:52

I ran into something similar before. One way to fix it, I think, but may take more space on your server than you want, is to run

bundle install --deployment

and then try to deploy. This does something like install all of your gems into the vendor folder, which I believe is generally good to avoid... but will still probably work. My app used to behave like this, my solution was removing exact versions to download from in my Gemfile, and then rebundling and deploying.

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

to

gem 'rails_admin'

Or you can do what it suggests, and Git your project off the production server onto a local machine, bundle it, and then repush onto your server. This solution might not be 100% correct but some of it worked for me... just thought I'd share. Goodluck

The `--deployment` flag did not make a difference unless I deleted the Gemfile.lock. Is that the way it's supposed to be? — JellicleCat, Jul 16 '12 at 23:04

score 1 · Answer 12 · answered Jun 26 '15 at 08:41

1

In our case we were using a feature that wasn't available in an old version of bundler which ran on our production machine. Therefore it was enough to upgrade bundler, i.e. do a gem update bundler.

answered Jun 26 '15 at 08:41

nerdinand

876
12
21

Thanks - I had this issue as well. Turned out to the version of bundler on the server was older than the one we were using on our desktops. – Nathan Bertram Feb 17 '16 at 19:59

score 1 · Answer 13 · answered Feb 08 '17 at 18:38

This might be a dangerous idea, but if absolutely must test something in a production deploy environment, you can edit the .bundle/config file

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

Now invoke bundle, in my case I needed to update a specific gem, so this my command

RAILS_ENV=production bundle update <whatever gem>

You should probably change it back after the update, so things work like you expect, afterwards. Again, this is probably unsupported, and YMMV

score 1 · Answer 14 · answered Jul 12 '18 at 06:13

1

This issue can be related to submodules pointing to old versions of code. For me, I resolved this issue by updating my submodules

If you have submodules, try running:

git submodule update --init

bundle install

answered Jul 12 '18 at 06:13

Gerard Simpson

2,026
2
30
45

Thanks for the pointer - turns out I didn't have my submodules initialized locally. running `git submodule update --init` and committing the resulting Gemfile.lock fixed the issue on Github Actions. – MikeMarsian Oct 02 '22 at 19:50

Meet Makwana · Answer 15 · 2023-07-22T11:58:44.527

The error message for the command bundle install in windows 10 (rails v-7) was like

You are trying to install in deployment mode after changing
your Gemfile. Run `bundle install` elsewhere and add the
If this is a development machine, remove the C:/Users/friends/Gemfile freeze
by running `bundle config unset deployment`.

The dependencies in your gemfile changed

You have added to the Gemfile:
* pg

You have deleted from the Gemfile:
* sqlite3 (~> 1.4)

Solution : So I did exactly the error message asked me to do. Ran the following command

bundle config unset deployment

And then I again ran bundle install and then it worked.

score 0 · Answer 16 · answered Sep 28 '13 at 02:20

0

I ran into this deploying a Nesta app after some gem updates. What worked for me was to delete the Gemfile.lock, run bundle install to re-generate it, and deploy again.

answered Sep 28 '13 at 02:20

Yarin

173,523
149
402
512

score 0 · Answer 17 · answered Jan 14 '14 at 15:20

0

I ran into a similar issue however I did both bundle install and bundle update and Heroku still rejected my push.

I fixed the issue by just deleting Gemfile.lock and then running bundle install again. I then added, committed, and pushed that to my git repo. After that I had no problem pushing to Heroku.

answered Jan 14 '14 at 15:20

Ryan Rich

11,637
8
22
31

Unless you have fixed your gem versions in your gemfile this is risky.. it might update gems and break your app – Abram Jan 10 '16 at 02:44

score 0 · Answer 18 · answered Dec 24 '16 at 05:31

for heroku, you don't have to change the syntax in the Gemfile. you can just add BUNDLE_GITHUB__HTTPS (note the double underscore) as an environment variable and set it to true (in your heroku app's dashboard under the Settings tab in the Config Vars section). this will switch the protocol from git:// to https:// for all such requests.

score 0 · Answer 19 · answered Jul 13 '17 at 00:48

0

I had the error message when attempting push to Heroku. I found the following solution fixed.

Git pull origin master
Git status
Git commit
Git push origin master
Git push heroku master

answered Jul 13 '17 at 00:48

Ben Strachan

1

score 0 · Answer 20 · answered Jan 28 '19 at 18:13

I read a dozen solutions on different resources but didn't find exactly what could help me in this situation

So I did find a solution. Exactly saying i read the error message attentively and there was a sollution: Run bundle install elsewhere. "Elsewhere" was my Cloud9 where i developed my app. So my steps

copy Gemfile and Gemfile.lock from server to local machine with rsync command
insert these two files into my RoR project (i used Cloud9)
open Gemfile and make changes that i want. In my case i added gem 'thin'
in terminal cd to my app on Cloud9 and run bundle install. in this case you will have a changed version of Gemfile.lock
copy new Gemfile and Gemfile.lock on server using rsync
cd to my app folder and again run bundle install --deployment --without development test DONE! Wish GOOD luck for all!

score 0 · Answer 21 · answered Dec 15 '22 at 10:47

As of the time of this writing Bundler support for capistrano defaults to "deployment: true", per

https://github.com/capistrano/bundler

So as opposed to trying to modify the bundle by hand after bundler [via capistrano] has laid it down, you may be able to solve the problem permanently by adding this to your deploy.rb or other Capistrano config file [you can do it just for one stage file as well if necessary]:

set :bundle_config, { deployment: false }

and then deploying again.

You will then notice in the "cap" output the following line [note I am using rvm here but you may not be]

.../rvm ruby-2.7.6@... do bundle config --local deployment false

Why did this stop working all of a sudden?

This is the $1M question, I never had to mess with this, but once I got to an Ubuntu 20.04.05 machine, suddenly, yes. Same cap files, same ruby version, same rails version, same OS version except the minor number.

Did it work?

Did this work for you? Leave me a comment and let me know.

Bundler: You are trying to install in deployment mode after changing your Gemfile

21 Answers21

Watch out for global Bundler config.

Why did this stop working all of a sudden?

Did it work?

Linked