38

We would test this, but don't want to risk ruining our dev environment if this isn't supposed to happen.

Is it okay to delete Gemfile.lock?

We're on Rails 3.0.6.

Crashalot
  • 33,605
  • 61
  • 269
  • 439

4 Answers4

37

You're probably not going to ruin your dev environment. However, you might end up with newer versions of gems than you had before. It depends on how you have defined them in Gemfile.

If you're using entries like:

gem "rails"

Then you'll get the latest rails gem, whatever that might be.

If you're using entries like:

gem "rails", "3.2.11"

Then you'll get 3.2.11 again.

Having said all of that, this is what branches are for. Make a branch in git, hg, or whatever you're using, blow away Gemfile.lock, run bundle install, and then check your test suite. If it's horrible, then you can abandon the branch while you figure out what went wrong.

Another tip: Any time I've ever wanted to do this, I found that it was useful to clear out all of my installed gems as well. If you're using rvm with gemsets this is as simple as running

rvm gemset empty [gemset_name]

jdl
  • 17,702
  • 4
  • 51
  • 54
9

It's ok to delete Gemfile.lock, just run

bundle install

to generate a new Gemfile.lock. Take note that if you didn't specify any version of a gem on your Gemfile, you will always get the latest

mpalencia
  • 5,481
  • 4
  • 45
  • 59
4

I know this has been answered already, but for everyone else that happens to come across this post on Google, you should know that command bundle init will regenerate the Gemfile.

Tom Hert
  • 947
  • 2
  • 10
  • 32
  • 2
    Hmm, for me I received an error message 'Gemfile already exists at /home/bla bla bla...`. It did not regenerate the file. Perhaps that means the .lock file can be removed and regenerated with `bundle init`, however if that is the case what would be the difference between that and simply bundle install? – Paul Richter Aug 21 '13 at 22:45
0

I've recently worked with this and there is a significant issue when deleting the gemfile.lock. If it is being generated in a separate remote environment, it could be created with separate platforms. Deleting the gemfile.lock locally would cause it to generate with the local platforms, that may be absent from the remote environment. This will cause it to fail in the remote environment.

Hywel Griffiths
  • 287
  • 5
  • 16