Why won't Heroku accept my Gemfile.lock in Windows?

12
votes

I have a rails application that I deploy on Heroku. I'm using several different machines, and I noticed that when I add new dependencies (so that Gemfile.lock is rebuilt) and do bundle install on my Windows computer at home, push to Heroku fails with the following error:

   Unresolved dependencies detected; Installing...
   Windows Gemfile.lock detected, ignoring it.
   You have modified your Gemfile in development but did not check
   the resulting snapshot (Gemfile.lock) into version control
   ...

Gemfile.lock IS under version control, but Heroku appearently chooses to ignore it since it's created in Windows, and then complains that it's missing seconds later. Why does this happen? And how can I solve it?

5
ruby-on-railsrubywindowsheroku
Something to do with CR/LF on Windows vs *nix? - Caley Woods
Maybe? Judging from the output from the failed push, it looks like Heroku is deliberately ignoring it. - mranders
Is bundler perhaps choosing precompiled windows binaries as dependencies and listing them in Gemfile.lock? - matt
Have a look at the question "Does Bundler work on Windows?" here: engineyard.com/blog/2011/bundler-pro-tip it looks like it could be related to your problem. - matt

5 Answers

9
votes

Like matt commented above:

The problem is that Bundler creates different Gemfile.locks for Windows. The only solution is to create and commit the lock file on a *NIX system.

I would suggest to create a virtual machine running e.g. Ubuntu – maybe using Virtual Box. You can even get ready-to-use virtual machines – for example here.

24
votes

I fixed mine by opening Gemfile.lock and deleting the following two lines: 

PLATFORMS
  x86-mingw32

So now i just need to make a script that bundles then removes that from the lock file.

4
votes

From the Heroku Docs:

If the platforms section of your Gemfile contains Windows entries, such as mswin or mingw, then the Gemfile.lock file will be ignored.

0
votes

Just battled through this problem for a while.

I trimmed my gemfile back to just rails and still had the issue. Then, thinking that heroku had demanded an update of the heroku gem today, I looked closer at heroku changes.

It seems the 1.9.2 ruby "bamboo" stack is now the default one - my app is still running on the 1.8.7 stack. So I ran "heroku stack:migrate bamboo-mri-1.9.2" and updated the stack to 1.9.2 - not something I wanted to do, but you know what, it fixed the issue above.

Of course, I didn't want to be on the 1.9.2 stack, so I migrated back down to the 1.8.7 stack, and things installed correctly again. So I think this is a workaround - and probably an overly complex one - but it seemed to "flush" whatever the error was heroku-side. As nothing I did locally (and I tried a LOT of things from StackOverflow articles) had any effect, the push just kept failing as above.

So yeah, this fixes it. Doesn't take too long either. But suspect a better workaround may be spotted by more heroku-knowledgeable developers !

-1
votes

Make sure you commit the changes to Gemfile.lock after installing the bundle. On your next push to Heroku, the new gems should be installed correctly.