bundler 1.0.21 → 1.1.rc

data/lib/bundler/man/bundle-install.txt

@@ -60,9 +60,9 @@ OPTIONS
 
        --local
 	      Do not attempt to connect to rubygems.org,  instead  using  just
-	      the  gems located in vendor/cache. Note that if a more appropri-
-	      ate platform-specific gem  exists  on  rubygems.org,  this  will
-	      bypass the normal lookup.
+	      the  gems already present in Rubygems' cache or in vendor/cache.
+	      Note that if a more appropriate platform-specific gem exists  on
+	      rubygems.org, it will not be found.
 
        --deployment
 	      Switches	bundler's  defaults  into  deployment mode. Do not use
@@ -82,11 +82,6 @@ OPTIONS
 	      also   generates	 a  bundle/bundler/setup.rb  file  to  replace
 	      Bundler's own setup.
 
-       --platform=<platform>
-	      Force the platform used by bundler to determine the gems	to  be
-	      installed.  By  default  bundler	will  use runtime detection to
-	      determine the target platform.
-
 DEPLOYMENT MODE
        Bundler's defaults are optimized for development. To switch to defaults
        optimized  for  deployment,  use the --deployment flag. Do not activate
@@ -129,14 +124,14 @@ DEPLOYMENT MODE
 
 
 SUDO USAGE
-       By default, bundler installs gems to the same location as gem  install.
+       By default, bundler installs gems to the same location as gem install.
 
-       In  some cases, that location may not be writable by your Unix user. In
+       In some cases, that location may not be writable by your Unix user.  In
        that case, bundler will stage everything in a temporary directory, then
-       ask  you  for  your  sudo password in order to copy the gems into their
+       ask you for your sudo password in order to copy	the  gems  into  their
        system location.
 
-       From your perspective,  this  is  identical  to	installing  them  gems
+       From  your  perspective,  this  is  identical  to  installing them gems
        directly into the system.
 
        You should never use sudo bundle install. This is because several other
@@ -150,36 +145,36 @@ SUDO USAGE
 
 
 
-       Of these three, the first  two  could  theoretically  be  performed  by
-       chowning  the  resulting  files	to $SUDO_USER. The third, however, can
-       only be performed by actually invoking the git command as  the  current
-       user.  Therefore,  git gems are downloaded and installed into ~/.bundle
+       Of  these  three,  the  first  two  could theoretically be performed by
+       chowning the resulting files to $SUDO_USER.  The  third,  however,  can
+       only  be  performed by actually invoking the git command as the current
+       user. Therefore, git gems are downloaded and installed  into  ~/.bundle
        rather than $GEM_HOME or $BUNDLE_PATH.
 
-       As a result, you should run bundle install as  the  current  user,  and
+       As  a  result,  you  should run bundle install as the current user, and
        bundler will ask for your password if it is needed to put the gems into
        their final location.
 
 INSTALLING GROUPS
-       By default, bundle install will install all gems in all groups in  your
+       By  default, bundle install will install all gems in all groups in your
        Gemfile(5), except those declared for a different platform.
 
-       However,  you  can  explicitly  tell bundler to skip installing certain
-       groups with the --without option. This option takes  a  space-separated
+       However, you can explicitly tell bundler  to  skip  installing  certain
+       groups  with  the --without option. This option takes a space-separated
        list of groups.
 
-       While  the --without option will skip installing the gems in the speci-
-       fied groups, it will still download those gems and use them to  resolve
+       While the --without option will skip installing the gems in the	speci-
+       fied  groups, it will still download those gems and use them to resolve
        the dependencies of every gem in your Gemfile(5).
 
        This is so that installing a different set of groups on another machine
-       (such as a production server) will not change  the  gems  and  versions
+       (such  as  a  production  server) will not change the gems and versions
        that you have already developed and tested against.
 
        Bundler offers a rock-solid guarantee that the third-party code you are
        running in development and testing is also the third-party code you are
-       running	in  production. You can choose to exclude some of that code in
-       different environments, but you will never  be  caught  flat-footed  by
+       running in production. You can choose to exclude some of that  code  in
+       different  environments,  but  you  will never be caught flat-footed by
        different versions of third-party code being used in different environ-
        ments.
 
@@ -197,86 +192,86 @@ INSTALLING GROUPS
 
 
 
-       In this case, sinatra depends on any version of	Rack  (>=  1.0,  while
+       In  this  case,	sinatra  depends on any version of Rack (>= 1.0, while
        rack-perftools-profiler depends on 1.x (~> 1.0).
 
-       When  you  run  bundle  install --without production in development, we
-       look at the dependencies of rack-perftools-profiler as well. That  way,
-       you  do	not spend all your time developing against Rack 2.0, using new
-       APIs unavailable in Rack 1.x, only to have bundler switch to  Rack  1.2
+       When you run bundle install --without  production  in  development,  we
+       look  at the dependencies of rack-perftools-profiler as well. That way,
+       you do not spend all your time developing against Rack 2.0,  using  new
+       APIs  unavailable  in Rack 1.x, only to have bundler switch to Rack 1.2
        when the production group is used.
 
-       This  should  not  cause  any  problems	in practice, because we do not
-       attempt to install the gems in the excluded groups, and	only  evaluate
+       This should not cause any problems  in  practice,  because  we  do  not
+       attempt	to  install the gems in the excluded groups, and only evaluate
        as part of the dependency resolution process.
 
-       This  also means that you cannot include different versions of the same
-       gem in different groups, because doing so  would  result  in  different
+       This also means that you cannot include different versions of the  same
+       gem  in	different  groups,  because doing so would result in different
        sets of dependencies used in development and production. Because of the
-       vagaries of the dependency resolution  process,	this  usually  affects
-       more  than just the gems you list in your Gemfile(5), and can (surpris-
+       vagaries  of  the  dependency  resolution process, this usually affects
+       more than just the gems you list in your Gemfile(5), and can  (surpris-
        ingly) radically change the gems you are using.
 
 REMEMBERED OPTIONS
-       Some options (marked above  in  the  OPTIONS  section)  are  remembered
+       Some  options  (marked  above  in  the  OPTIONS section) are remembered
        between calls to bundle install, and by the Bundler runtime.
 
-       For  instance,  if  you run bundle install --without test, a subsequent
-       call to bundle install that does not  include  a  --without  flag  will
+       For instance, if you run bundle install --without  test,  a  subsequent
+       call  to  bundle  install  that	does not include a --without flag will
        remember your previous choice.
 
-       In  addition, a call to Bundler.setup will not attempt to make the gems
-       in those groups available on the Ruby  load  path,  as  they  were  not
+       In addition, a call to Bundler.setup will not attempt to make the  gems
+       in  those  groups  available  on  the  Ruby load path, as they were not
        installed.
 
        The settings that are remembered are:
 
        --deployment
-	      At  runtime, this remembered setting will also result in Bundler
+	      At runtime, this remembered setting will also result in  Bundler
 	      raising an exception if the Gemfile.lock is out of date.
 
-       --path Subsequent calls to bundle install  will	install  gems  to  the
-	      directory  originally passed to --path. The Bundler runtime will
-	      look for gems in that location. You can revert  this  option  by
+       --path Subsequent  calls  to  bundle  install  will install gems to the
+	      directory originally passed to --path. The Bundler runtime  will
+	      look  for  gems  in that location. You can revert this option by
 	      running bundle install --system.
 
        --binstubs
-	      Bundler  will  update  the  executables every subsequent call to
+	      Bundler will update the executables  every  subsequent  call  to
 	      bundle install.
 
        --without
-	      As described above, Bundler will	skip  the  gems  specified  by
-	      --without  in  subsequent  calls	to bundle install. The Bundler
+	      As  described  above,  Bundler  will  skip the gems specified by
+	      --without in subsequent calls to	bundle	install.  The  Bundler
 	      runtime will also not try to make the gems in the skipped groups
 	      available.
 
 THE GEMFILE.LOCK
-       When  you  run  bundle install, Bundler will persist the full names and
-       versions of all gems that you used (including dependencies of the  gems
+       When you run bundle install, Bundler will persist the  full  names  and
+       versions  of all gems that you used (including dependencies of the gems
        specified in the Gemfile(5)) into a file called Gemfile.lock.
 
        Bundler uses this file in all subsequent calls to bundle install, which
        guarantees that you always use the same exact code, even as your appli-
        cation moves across machines.
 
-       Because	of the way dependency resolution works, even a seemingly small
+       Because of the way dependency resolution works, even a seemingly  small
        change (for instance, an update to a point-release of a dependency of a
-       gem  in	your  Gemfile(5)) can result in radically different gems being
+       gem in your Gemfile(5)) can result in radically	different  gems  being
        needed to satisfy all dependencies.
 
-       As a result, you SHOULD check your Gemfile.lock into  version  control.
+       As  a  result, you SHOULD check your Gemfile.lock into version control.
        If you do not, every machine that checks out your repository (including
        your production server) will resolve all dependencies again, which will
-       result  in  different versions of third-party code being used if any of
-       the gems in the Gemfile(5) or  any  of  their  dependencies  have  been
+       result in different versions of third-party code being used if  any  of
+       the  gems  in  the  Gemfile(5)  or  any of their dependencies have been
        updated.
 
 CONSERVATIVE UPDATING
-       When  you  make a change to the Gemfile(5) and then run bundle install,
+       When you make a change to the Gemfile(5) and then run  bundle  install,
        Bundler will update only the gems that you modified.
 
-       In other words, if a gem that you did  not  modify  worked  before  you
-       called  bundle install, it will continue to use the exact same versions
+       In  other  words,  if  a  gem that you did not modify worked before you
+       called bundle install, it will continue to use the exact same  versions
        of all dependencies as it used before the update.
 
        Let's take a look at an example. Here's your original Gemfile(5):
@@ -290,13 +285,13 @@ CONSERVATIVE UPDATING
 
 
 
-       In this case, both actionpack and activemerchant depend	on  activesup-
-       port.  The  actionpack  gem  depends on activesupport 2.3.8 and rack ~>
-       1.1.0, while the activemerchant gem depends on activesupport >=	2.3.2,
+       In  this  case, both actionpack and activemerchant depend on activesup-
+       port. The actionpack gem depends on activesupport  2.3.8  and  rack  ~>
+       1.1.0,  while the activemerchant gem depends on activesupport >= 2.3.2,
        braintree >= 2.0.0, and builder >= 2.0.0.
 
-       When   the   dependencies  are  first  resolved,  Bundler  will	select
-       activesupport 2.3.8, which satisfies the requirements of both  gems  in
+       When  the  dependencies	are  first  resolved,  Bundler	 will	select
+       activesupport  2.3.8,  which satisfies the requirements of both gems in
        your Gemfile(5).
 
        Next, you modify your Gemfile(5) to:
@@ -310,40 +305,40 @@ CONSERVATIVE UPDATING
 
 
 
-       The  actionpack	3.0.0.rc  gem  has  a  number of new dependencies, and
-       updates the activesupport dependency to = 3.0.0.rc and the rack	depen-
+       The actionpack 3.0.0.rc gem has	a  number  of  new  dependencies,  and
+       updates	the activesupport dependency to = 3.0.0.rc and the rack depen-
        dency to ~> 1.2.1.
 
-       When  you  run  bundle  install,  Bundler  notices that you changed the
-       actionpack gem, but not the activemerchant gem. It evaluates  the  gems
+       When you run bundle install,  Bundler  notices  that  you  changed  the
+       actionpack  gem,  but not the activemerchant gem. It evaluates the gems
        currently being used to satisfy its requirements:
 
        activesupport 2.3.8
-	      also  used  to  satisfy a dependency in activemerchant, which is
+	      also used to satisfy a dependency in  activemerchant,  which  is
 	      not being updated
 
        rack ~> 1.1.0
 	      not currently being used to satify another dependency
 
-       Because you did not explicitly ask to update activemerchant, you  would
-       not  expect it to suddenly stop working after updating actionpack. How-
-       ever, satisfying the new activesupport 3.0.0.rc dependency  of  action-
+       Because	you did not explicitly ask to update activemerchant, you would
+       not expect it to suddenly stop working after updating actionpack.  How-
+       ever,  satisfying  the new activesupport 3.0.0.rc dependency of action-
        pack requires updating one of its dependencies.
 
-       Even  though activemerchant declares a very loose dependency that theo-
-       retically matches activesupport 3.0.0.rc, bundler treats gems  in  your
-       Gemfile(5)  that have not changed as an atomic unit together with their
+       Even though activemerchant declares a very loose dependency that  theo-
+       retically  matches  activesupport 3.0.0.rc, bundler treats gems in your
+       Gemfile(5) that have not changed as an atomic unit together with  their
        dependencies. In this case, the activemerchant dependency is treated as
-       activemerchant  1.7.1  +  activesupport	2.3.8,	so bundle install will
+       activemerchant 1.7.1 + activesupport  2.3.8,  so  bundle  install  will
        report that it cannot update actionpack.
 
        To explicitly update actionpack, including its dependencies which other
-       gems  in  the  Gemfile(5) still depend on, run bundle update actionpack
+       gems in the Gemfile(5) still depend on, run  bundle  update  actionpack
        (see bundle update(1)).
 
-       Summary: In general, after making a change  to  the  Gemfile(5)	,  you
-       should  first  try  to run bundle install, which will guarantee that no
-       other gems in the Gemfile(5) are impacted by the change. If  that  does
+       Summary:  In  general,  after  making  a change to the Gemfile(5) , you
+       should first try to run bundle install, which will  guarantee  that  no
+       other  gems  in the Gemfile(5) are impacted by the change. If that does
        not work, run bundle update(1) bundle-update.1.html.
 
 

data/lib/bundler/man/bundle-package

@@ -1,7 +1,7 @@
 .\" generated with Ronn/v0.7.3
 .\" http://github.com/rtomayko/ronn/tree/0.7.3
 .
-.TH "BUNDLE\-PACKAGE" "1" "October 2010" "" ""
+.TH "BUNDLE\-PACKAGE" "1" "January 2011" "" ""
 .
 .SH "NAME"
 \fBbundle\-package\fR \- Package your needed \fB\.gem\fR files into your application

data/lib/bundler/man/bundle-package.txt

@@ -63,4 +63,4 @@ REMOTE FETCHING
 
 
 
-				 October 2010		     BUNDLE-PACKAGE(1)
+				 January 2011		     BUNDLE-PACKAGE(1)

data/lib/bundler/man/bundle-update

@@ -1,7 +1,7 @@
 .\" generated with Ronn/v0.7.3
 .\" http://github.com/rtomayko/ronn/tree/0.7.3
 .
-.TH "BUNDLE\-UPDATE" "1" "October 2010" "" ""
+.TH "BUNDLE\-UPDATE" "1" "January 2011" "" ""
 .
 .SH "NAME"
 \fBbundle\-update\fR \- Update your gems to the latest available versions

data/lib/bundler/man/bundle-update.txt

@@ -14,18 +14,18 @@ DESCRIPTION
        eral, you should use bundle install(1) bundle-install.1.html to install
        the same exact gems and versions across machines.
 
-       You would use bundle update to explicitly update the version of a  gem.
+       You would use bundle update to explicitly update the version of a gem.
 
 OPTIONS
        --source=<name>
-	      The  name  of a :git or :path source used in the Gemfile(5). For
-	      instance,       with	 a	  :git	      source	    of
-	      http://github.com/rails/rails.git,  you would call bundle update
+	      The name of a :git or :path source used in the  Gemfile(5).  For
+	      instance,        with	   a	    :git       source	    of
+	      http://github.com/rails/rails.git, you would call bundle	update
 	      --source rails
 
 UPDATING ALL GEMS
-       If you run bundle update with no parameters, bundler  will  ignore  any
-       previously  installed  gems and resolve all dependencies again based on
+       If  you	run  bundle update with no parameters, bundler will ignore any
+       previously installed gems and resolve all dependencies again  based  on
        the latest versions of all gems available in the sources.
 
        Consider the following Gemfile(5):
@@ -39,8 +39,8 @@ UPDATING ALL GEMS
 
 
 
-       When you run bundle install(1) bundle-install.1.html  the  first  time,
-       bundler	will  resolve  all  of the dependencies, all the way down, and
+       When  you  run  bundle install(1) bundle-install.1.html the first time,
+       bundler will resolve all of the dependencies, all  the  way  down,  and
        install what you need:
 
 
@@ -76,44 +76,44 @@ UPDATING ALL GEMS
 
 
 
-       As you can see, even though you have just two gems in  the  Gemfile(5),
-       your  application  actually  needs  25  different gems in order to run.
-       Bundler remembers the exact versions it installed in Gemfile.lock.  The
-       next  time  you	run  bundle  install(1) bundle-install.1.html, bundler
-       skips the dependency resolution	and  installs  the  same  gems	as  it
+       As  you	can see, even though you have just two gems in the Gemfile(5),
+       your application actually needs 25 different  gems  in  order  to  run.
+       Bundler	remembers the exact versions it installed in Gemfile.lock. The
+       next time you  run  bundle  install(1)  bundle-install.1.html,  bundler
+       skips  the  dependency  resolution  and	installs  the  same gems as it
        installed last time.
 
-       After  checking in the Gemfile.lock into version control and cloning it
-       on another machine,  running  bundle  install(1)  bundle-install.1.html
-       will  still  install  the  gems that you installed last time. You don't
+       After checking in the Gemfile.lock into version control and cloning  it
+       on  another  machine,  running  bundle install(1) bundle-install.1.html
+       will still install the gems that you installed  last  time.  You  don't
        need to worry that a new release of erubis or mail changes the gems you
        use.
 
-       However,  from  time to time, you might want to update the gems you are
-       using to the newest versions that still match the  gems	in  your  Gem-
+       However, from time to time, you might want to update the gems  you  are
+       using  to  the  newest  versions that still match the gems in your Gem-
        file(5).
 
-       To  do this, run bundle update, which will ignore the Gemfile.lock, and
-       resolve all the dependencies again. Keep in mind that this process  can
-       result  in  a  significantly different set of the 25 gems, based on the
-       requirements of new gems that the gem authors released since  the  last
+       To do this, run bundle update, which will ignore the Gemfile.lock,  and
+       resolve	all the dependencies again. Keep in mind that this process can
+       result in a significantly different set of the 25 gems,	based  on  the
+       requirements  of  new gems that the gem authors released since the last
        time you ran bundle update.
 
 UPDATING A LIST OF GEMS
        Sometimes, you want to update a single gem in the Gemfile(5), and leave
-       the rest of the gems that you specified locked to the versions  in  the
+       the  rest  of the gems that you specified locked to the versions in the
        Gemfile.lock.
 
-       For  instance,  in  the	scenario above, imagine that nokogiri releases
+       For instance, in the scenario above,  imagine  that  nokogiri  releases
        version 1.4.4, and you want to update it without updating Rails and all
        of its dependencies. To do this, run bundle update nokogiri.
 
-       Bundler	will  update  nokogiri	and any of its dependencies, but leave
+       Bundler will update nokogiri and any of	its  dependencies,  but  leave
        alone Rails and its dependencies.
 
 OVERLAPPING DEPENDENCIES
-       Sometimes, multiple gems declared in your Gemfile(5) are  satisfied  by
-       the  same  second-level	dependency. For instance, consider the case of
+       Sometimes,  multiple  gems declared in your Gemfile(5) are satisfied by
+       the same second-level dependency. For instance, consider  the  case  of
        thin and rack-perftools-profiler.
 
 
@@ -125,7 +125,7 @@ OVERLAPPING DEPENDENCIES
 
 
 
-       The thin gem depends on	rack  >=  1.0,	while  rack-perftools-profiler
+       The  thin  gem  depends	on  rack >= 1.0, while rack-perftools-profiler
        depends on rack ~> 1.0. If you run bundle install, you get:
 
 
@@ -143,24 +143,24 @@ OVERLAPPING DEPENDENCIES
 
 
        In this case, the two gems have their own set of dependencies, but they
-       share rack in common. If you  run  bundle  update  thin,  bundler  will
-       update  daemons, eventmachine and rack, which are dependencies of thin,
-       but  not   open4   or   perftools.rb,   which   are   dependencies   of
-       rack-perftools_profiler.  Note that bundle update thin will update rack
+       share  rack  in	common.  If  you  run bundle update thin, bundler will
+       update daemons, eventmachine and rack, which are dependencies of  thin,
+       but   not   open4   or	perftools.rb,	which	are   dependencies  of
+       rack-perftools_profiler. Note that bundle update thin will update  rack
        even though it's also a dependency of rack-perftools_profiler.
 
-       In short, when you update a  gem  using	bundle	update,  bundler  will
-       update  all  dependencies  of  that  gem, including those that are also
+       In  short,  when  you  update  a  gem using bundle update, bundler will
+       update all dependencies of that gem,  including	those  that  are  also
        dependencies of another gem.
 
        In this scenario, updating the thin version manually in the Gemfile(5),
-       and  then  running  bundle  install(1)  bundle-install.1.html will only
-       update daemons and eventmachine, but not rack.  For  more  information,
+       and then running  bundle  install(1)  bundle-install.1.html  will  only
+       update  daemons	and  eventmachine, but not rack. For more information,
        see  the  CONSERVATIVE  UPDATING  section  of  bundle  install(1)  bun-
        dle-install.1.html.
 
 RECOMMENDED WORKFLOW
-       In general, when working with an application managed with bundler,  you
+       In  general, when working with an application managed with bundler, you
        should use the following workflow:
 
        o   After you create your Gemfile(5) for the first time, run
@@ -171,7 +171,7 @@ RECOMMENDED WORKFLOW
 
 	   $ git add Gemfile.lock
 
-       o   When  checking  out this repository on another development machine,
+       o   When checking out this repository on another  development  machine,
 	   run
 
 	   $ bundle install
@@ -180,7 +180,7 @@ RECOMMENDED WORKFLOW
 
 	   $ bundle install --deployment
 
-       o   After changing the Gemfile(5) to reflect a  new  or	update	depen-
+       o   After  changing  the  Gemfile(5)  to reflect a new or update depen-
 	   dency, run
 
 	   $ bundle install
@@ -194,7 +194,7 @@ RECOMMENDED WORKFLOW
 
 	   $ bundle update rails thin
 
-       o   If you want to update all the gems to the latest possible  versions
+       o   If  you want to update all the gems to the latest possible versions
 	   that still match the gems listed in the Gemfile(5), run
 
 	   $ bundle update
@@ -204,4 +204,4 @@ RECOMMENDED WORKFLOW
 
 
 
-				 October 2010		      BUNDLE-UPDATE(1)
+				 January 2011		      BUNDLE-UPDATE(1)

data/lib/bundler/man/gemfile.5

@@ -1,7 +1,7 @@
 .\" generated with Ronn/v0.7.3
 .\" http://github.com/rtomayko/ronn/tree/0.7.3
 .
-.TH "GEMFILE" "5" "September 2011" "" ""
+.TH "GEMFILE" "5" "October 2011" "" ""
 .
 .SH "NAME"
 \fBGemfile\fR \- A format for describing gem dependencies for Ruby programs
@@ -63,20 +63,22 @@ gem "RedCloth", ">= 4\.1\.0", "< 4\.2\.0"
 .IP "" 0
 .
 .SS "REQUIRE AS (:require)"
-Each \fIgem\fR \fBMAY\fR specify its main file, which should be used when autorequiring (\fBBundler\.require\fR)\.
+Each \fIgem\fR \fBMAY\fR specify files that should be used when autorequiring via \fBBundler\.require\fR\. You may pass an array with multiple files, or \fBfalse\fR to prevent any file from being autorequired\.
 .
 .IP "" 4
 .
 .nf
 
 gem "sqlite3\-ruby", :require => "sqlite3"
+gem "redis", :require => ["redis/connection/hiredis", "redis"]
+gem "webmock", :require => false
 .
 .fi
 .
 .IP "" 0
 .
 .P
-This defaults to the name of the gem itself\. For instance, these are identical:
+The argument defaults to the name of the gem\. For example, these are identical:
 .
 .IP "" 4
 .
@@ -89,9 +91,6 @@ gem "nokogiri", :require => "nokogiri"
 .
 .IP "" 0
 .
-.P
-Specify \fB:require => false\fR to prevent bundler from requiring the gem, but still install it and maintain dependencies\.
-.
 .SS "GROUPS (:group or :groups)"
 Each \fIgem\fR \fBMAY\fR specify membership in one or more groups\. Any \fIgem\fR that does not specify membership in any group is placed in the \fBdefault\fR group\.
 .
@@ -365,7 +364,7 @@ The source explicitly attached to the gem (using \fB:path\fR or \fB:git\fR)
 For implicit gems (dependencies of explicit gems), any git or path repository otherwise declared\. This results in bundler prioritizing the ActiveSupport gem from the Rails git repository over ones from \fBrubygems\.org\fR
 .
 .IP "3." 4
-The sources specified via \fBsource\fR, in the order in which they were declared in the \fBGemfile\fR\.
+The sources specified via \fBsource\fR, searching each source in your \fBGemfile\fR from last added to first added\.
 .
 .IP "" 0
 

data/lib/bundler/man/gemfile.5.txt

@@ -54,16 +54,19 @@ GEMS (#gem)
 
 
    REQUIRE AS (:require)
-       Each  gem  MAY specify its main file, which should be used when autore-
-       quiring (Bundler.require).
+       Each  gem  MAY specify files that should be used when autorequiring via
+       Bundler.require. You may pass an array with multiple files, or false to
+       prevent any file from being autorequired.
 
 
 
 	   gem "sqlite3-ruby", :require => "sqlite3"
+	   gem "redis", :require => ["redis/connection/hiredis", "redis"]
+	   gem "webmock", :require => false
 
 
 
-       This defaults to the name of the gem itself. For  instance,  these  are
+       The  argument  defaults	to the name of the gem. For example, these are
        identical:
 
 
@@ -73,9 +76,6 @@ GEMS (#gem)
 
 
 
-       Specify	:require  =>  false to prevent bundler from requiring the gem,
-       but still install it and maintain dependencies.
-
    GROUPS (:group or :groups)
        Each gem MAY specify membership in one or more  groups.	Any  gem  that
        does  not  specify  membership  in  any	group is placed in the default
@@ -337,12 +337,12 @@ SOURCE PRIORITY
 	   the ActiveSupport gem from the Rails git repository over ones  from
 	   rubygems.org
 
-       3.  The	sources  specified via source, in the order in which they were
-	   declared in the Gemfile.
+       3.  The	sources  specified  via  source, searching each source in your
+	   Gemfile from last added to first added.
 
 
 
 
 
 
-				September 2011			    GEMFILE(5)
+				 October 2011			    GEMFILE(5)

data/lib/bundler/match_platform.rb

@@ -0,0 +1,13 @@
+require 'bundler/gem_helpers'
+
+module Bundler
+  module MatchPlatform
+    include GemHelpers
+
+    def match_platform(p)
+      Gem::Platform::RUBY == platform or
+      platform.nil? or p == platform or
+      generic(Gem::Platform.new(platform)) == p
+    end
+  end
+end