What Happens When Modifying Gemfile.Lock Directly

What happens when modifying Gemfile.lock directly?

If you edit your Gemfile.lock then Rails app would depend on another versions of gems... The integrity of your gem-versioning system would be broken in this case. It's a very-very bad idea to edit Gemfile.lock file directly.

Please, be a good guy and make deals with Gemfile only

Updating Gemfile.lock without installing gems

Run bundle lock --update.

I found an answer in a blog post by Chris Blunt: “Rails on Docker: Quickly Create or Update Your Gemfile.lock”:

Today, I discovered a way to save the hours wasted downloading gems: bundler’s lock command.

This gem of a command resolves your app’s dependencies and writes out the appropriate Gemfile.lock – without installing any of the gems themselves.

According to the changelog, this command was added in Bundler 1.10.0.pre, released about eight months after this question was asked.

Understanding Gemfile.lock: Is it okay to delete Gemfile.lock then run bundle install again?

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]

modified: Gemfile.lock , Why?

I think it is because you ran

bundle install

it will change the Gemfile.lock to tell exactly what versions of each gem your project is using so that when something breaks, you can trace back what versions of gem you were using earlier.

Something keeps rewriting my Gemfile.lock

Found the culprit, thanks to this answer (this answer concurs): Spring. There were half a dozen rogue spring processes on my machine, and any or all of them must have been regenerating the file. Killing those processes solved the problem, and so far adding export DISABLE_SPRING=1 to my .bash_profile seems to have kept it from recurring.

(spring stop might have worked too. I don't know whether it stops all Spring processes or just one of them, though.)

How to deal with bundler updates (Gemfile.lock) in collaborative context?

Gemfile.lock should be version controlled. You should be committing any changes to it. When somebody (who you trust) updates it, you should run bundle install to install the gems currently locked in Gemfile.lock.

Just running bundle install will not update an existing Gemfile.lock. To do so, you need to run bundle update.

All that said, there are no actual changes to the versions in your Gemfile.lock. All that changed was the order of arguments for a few lines. You can safely merge those changes in or disregard them; the resulting Gemfile.lock will be (functionally) identical.

---

Related Topics