How do I keep all gems in Gemfile compatible after an update

Question

My question has already been asked here, but I am trying to understand the reasons behind it as opposed to how to work around it.

The error I got was;

You have already activated rspec-core 2.7.1, but your Gemfile requires rspec-core 2.6.4. Using bundle exec may solve this. (Gem::LoadError)

Now I have been given various solutions like using "mpapis-bundler", or to create a shorthand for "bundle exec", but I was under the impression that that was what

$bundle install --binstubs

was for.

More specifically, since I have no version numbers stated in my gemfile for rspec-rails, why do I have this incompatibility? My error also occurred when I tried

$rake db:migrate

telling me that

You have already activated rake 0.9.2.2, but your Gemfile requires rake 0.9.2. Consider using bundle exec.

Any explanations would be appreciated.

EDIT:
All my gems for my app are in a gemset, and I have updated my gems again. Should an update not make sure that related gems are compatible?

Solution 1

This happens when you install more recent gems in your system than the one in your Rails app.

Bundler simply tells ou that you must stick with those your Gemfile states.

This is the purpose of running:

bundle exec rake db:migrate

-> running the very same rake version your Gemfile provides.

Concerning updating gems from gemfile, simply do:

bundle update

The easiest way to avoid this kind of boring stuff is to isolate your gems by creating gemsets. I use RVM for this purpose.

Solution 2

Regarding the rake version 0.9.2.2, either ways to do is create a new gemset for the project and maintain the gem version matching your Gemfile.

For instance if there are two rake gem containing versions 0.9.2 and 0.9.2.2, specifying rake version '0.9.2' though installs, but does not run any tasks apart from blowing error saying

'You have already activated rake 0.9.2.2, but your Gemfile requires rake 0.9.2. Using bundle exec may solve this.'

I expect bundle install to lock the gem version in Gemfile.lock and pick the rake 0.9.2, but it looks in the gemset, where by default rake 0.9.2.2 is enabled.

Just reminding the purpose of bundle install from agile web development with rails book,

'bundle install will use the Gemfile.lock as a starting point, and install only the versions of the various gems as specified in this file. For this reason, it is important that this file gets checked into your version control system, as this will ensure that your colleagues and deployment targets will all be using the exact same configuration.'

but it doesn't work that way,

The better is to uninstall rake 0.9.2.2 and use rake 0.9.2 or, use bundle update rake, that updates the rake version in Gemfile.lock to 0.9.2.2

Comments

[Theo Scholiadis]

I am, indeed, using rvm, and I do have a gemset. This error occurred after I ran "$bundle update" as I wanted to update the "annotate" gem (the version I had was incompatible with Rails 3.1). I was under the impression that running "$bundle update" will update all gems in the Gemfile.lock, and since I have no version numbers, it will update them to the newest. I expected that rspec would update all relevant gems to the ones that are compatible. Am I wrong?

[apneadiving]

do you have a dedicated gemset? do you have a .rvmrc file loading it? is you global gemset empty?

[Theo Scholiadis]

I have a .rvmrc file loading my gemset. I haven't installed any gems in the global. How do I check that?

[apneadiving]

1. use the gemset yo want to test: rvm gemset use foo. 2. List the gems inside: gem list

[Theo Scholiadis]

Thanks. The global gemset is empty. I remember I had emptied it so that I made sure I have only gems in the gemset of my rails app.

[c3rin]

In my case when I do gem list I get rake (0.9.2.2, 0.9.2). I can't seem to uninstall 0.9.2.2 with gem uninstall rake. Is there a way to remove 0.9.2.2 from my gemset?

[Theo Scholiadis]

Fair enough. I was wondering, though, why it didn't automatically update all the required gems, cause I have no version numbers in the Gemfile for this reason. This is a good workaround for the specific problem, not for all instances.