User:Jitendra92/Bundler

 Bundler  is an application-level  gem  dependency manager for Ruby written under MIT License. Ruby applications like any other software application have  dependencies on other Ruby  libraries and  frameworks called  gems to use certain features. Before an application can start using features from other gems, it needs to install those gems through a package manager like RubyGems which allows gems to be manually installed for the application one by one.

Bundler automates the installation process by tracking and installing the exact gems your application needs together with the required versions of their dependencies. It not only helps in installation of gems but also manages them throughout their lifecycle.

Additionally, Bundler checks the compatibility between the specified gem versions along with their dependencies before installing them. It also allows updating one or more gems to newer versions when they are available. By tracking and locking the versions of all gems and their dependencies, it allows application programmers to run the same ruby code on every machine ensuring easy code distribution.

Require method
One of the oldest ways in Ruby to share code is the require method. It dates back to the year 1997. Require method takes in a filename, and loads that file exactly once. The require method makes use of the two important globals $LOADED_FEATURES and $LOAD_PATHS. Working of require method can be logically represented through the following code snippet. $LOADED_FEATURES maintains the list of all the files that have been ‘required’ once. So that the same code doesn’t run twice if require method gets called again. To solve the problem of code being distributed in multiple directories and to provide absolute paths for the files in require method, global $LOAD_PATH is needed. This can be thought of as a list of directories to look into once require method is called.

Setup.rb and The Ruby Application Archive
Setup.rb and Ruby Application Archive (RAA) combination for sharing code became popular with Ruby developers from the year 2004. At its core, setup.rb is a Ruby implementation of a set of three commands ( ruby setup.rb config, ruby setup.rb setup and ruby setup.rb install ) to install libraries .A developer had to browse through RAA looking for library and the version he needed, download the .tar.gz file containing the library, decompress the tar, and from the directory run ruby setup.rb. For updating the library same process had to be repeated as getting a new library. This did not support multiple version install so it created a problem if two applications running on a same environment needed different library versions. RAA was shut down on August 4, 2013 due to lack of resources. Setup.rb still exists but the code has not been maintained since the year 2005. .

RubyGems
In 2004 RubyGems came into existence. Developers could now install and list gems through single commands like gem list and gem install. Also it solved the existing problem by introducing installation of multiple gem versions. It provided its own patches to the require method. If no version of a gem was installed, it installs the newest version available. Developers could now call require for different versions of gem. This revolutionized code sharing in Ruby, and many libraries came up. But with increasing number of gems and their versions, managing dependencies became tougher. Every platform where the application is running had to install the same version of gem, which could create dependency problem for some other application running on the same server. Many solutions like config.gem and gem_installer came up but they failed because RubyGems would simply install the newest available version. Gem activation errors where RubyGems was asked to install a version of the gem and then later on asks to install another version also became very common.

Bundler
The problem with RubyGems was dependency resolution at runtime. Developers had to manually figure out a set of gem versions which would work together before the application runs, this is commonly known as dependency graph resolution problem. Bundler automates this process. Bundler tries various combinations of versions before one combination works. Over the years, it has developed various heuristics to figure out which combination to try first. With this dependency resolution, it has become very fast and takes few seconds for most of the Gemfiles.

Gemfile
This file is used to specify a list of all the gems (dependencies) with their versions (optional) which the application requires Bundler to install and manage.

In the above shown example Gemfile, the first line defines the source which bundler will be using to fetch the listed gems in this file. The following lines declare the list of gems with their versions (optional)

Gemfile.lock
The file snapshots the exact versions of all the gems installed by Bundler. It not only includes the gems present in the Gemfile but also their dependencies. This allows Bundler to install all the dependencies of the application with their exact versions defined in this file on another machine instead of performing dependency resolution using the  Gemfile. This file is automatically generated by bundler after a bundle install.

Getting started

 * 1) Open the terminal and install bundler gem using the command
 * 2) List the gems required by the application in Gemfile
 * You may include gem version in the file if you need a specific one.
 * 1) Install the listed gems and their dependencies using command
 * If Gemfile.lock is not present and bundle install is run for the first time, all remote sources are fetched, dependencies are resolved and all needed gems are installed.
 * If Gemfile.lock is present bundler will use all gem versions specified in Gemfile.lock instead of resolving dependencies. In case Gemfile is updated, bundler will re-resolve dependencies for updated gems and use versions from Gemfile.lock for gems which were not updated.
 * 1) Checkin Gemfile.lock to your repository so that other developers of the application use same version of the third party code.
 * If Gemfile.lock is not present and bundle install is run for the first time, all remote sources are fetched, dependencies are resolved and all needed gems are installed.
 * If Gemfile.lock is present bundler will use all gem versions specified in Gemfile.lock instead of resolving dependencies. In case Gemfile is updated, bundler will re-resolve dependencies for updated gems and use versions from Gemfile.lock for gems which were not updated.
 * 1) Checkin Gemfile.lock to your repository so that other developers of the application use same version of the third party code.

Supported Frameworks

 * Rails 3
 * Rails 2.3
 * Sinatra
 * RubyGems
 * RubyMotion