What is the difference between updating a package and a package?

Question

I get two different results when using two bundle and bundle update commands

If I use bundle update , I get the following error:

 Resolving dependencies... Bundler could not find compatible versions for gem "railties": In Gemfile: requirejs-rails (>= 0) ruby depends on railties (~> 3.1.1) ruby rails (= 4.0.0.rc2) ruby depends on railties (4.0.0.rc2) Bundler could not find compatible versions for gem "rails": In Gemfile: requirejs-rails (>= 0) ruby depends on rails (~> 3.1.1) ruby rails (4.0.0.rc2) 

But if I use only bundle , I get the following:

 Resolving dependencies... Bundler could not find compatible versions for gem "activesupport": In snapshot (Gemfile.lock): activesupport (3.2.2) In Gemfile: rails (= 4.0.0.rc2) ruby depends on activesupport (= 4.0.0.rc2) ruby Running `bundle update` will rebuild your snapshot from scratch, using only the gems in your Gemfile, which may resolve the conflict. 

Errors point to two different dependency problems, but both fetching gem metadata from https://rubygems.org/... and Resolving dependencies... fetching gem metadata from https://rubygems.org/... , so how do they differ?

I always used only bundle , but tried bundle update and noticed the difference.

Answer 1

In a nutshell: bundle install processes the changes to the Gemfile and the service pack updates the gems that are already managed by the Bundler.

http://viget.com/extend/bundler-best-practices

Needless to say, bundle and bundle install are the same command, install is the default option for bundle .

Answer 2

bundle matches bundle install , which does the following:

• Check if Gemfile.lock . If so, install all the gems with the exact version listed there.
• If the lock does not exist, install gems as specified in the Gemfile , using the latest available / valid versions according to the Gemfile . Then create a Gemfile.lock to record which versions were installed.

bundle update , on the other hand, removes / ignores your Gemfile.lock and goes directly to step 2.

The error you see is probably due to the fact that some pearls want active_support be in the version 3.xx range, while you seem to be trying to upgrade to Rails 4.