After creating your new app with “rails new my_app”, the next step is to change directories into your my_app directory and run “bundle install”.
Again, we get a ton of output from a simple command:
Using rake 10.4.2
Using i18n 0.7.0
Using json 1.8.2
Using minitest 5.5.1
Using thread_safe 0.3.4
Using tzinfo 1.2.2
More Rails magic?
Well, kind of. This time most of the magic is coming from a gem called Bundler.
I wasn’t around during the dark ages of Rails development, but I presume that before Bundler came along, Rails developers had to venture out with spear in hand, and hunt down each individual gem their app depended on, and then each gem that those gems depended on.
When you run “bundle install” you’re telling Bundler:
- Look in the file named Gemfile
- Go to the RubyGems API (or whichever source is declared at the top of the Gemfile).
- Find all the gems listed in the Gemfile plus all the gems that those gems depend on.
- If the gem is already installed, use that. If not, install it.
- Take a snapshot of the full gem list and store it in Gemfile.lock
- Add the gems to the load path, making them available to every file in the app. (This saves you the step of having to specifically require each gem in any file that will need it).
Never make changes to Gemfile.lock. That file is for Bundler’s use only.
The problem with editing Gemfile.lock directly is that it will be overwritten the next time you run “bundle install”. Instead, add new gems to Gemfile and run “bundle install”. Bundler will take care of updating Gemfile.lock.
Go ahead and take a look at the default Gemfile and Gemfile.lock that are created when you run “rails new”. See how many more lines are in Gemfile.lock? That will give you an idea of just how much work Bundler does for you.