bundler 1.16.2 → 1.16.3

data/man/bundle-update.1.txt

@@ -13,7 +13,7 @@ SYNOPSIS
 DESCRIPTION
        Update  the  gems specified (all gems, if none are specified), ignoring
        the previously installed gems specified in the  Gemfile.lock.  In  gen-
-       eral,  you should use [bundle install(1)][bundle-install(1)] to install
+       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.
@@ -91,7 +91,7 @@ UPDATING ALL GEMS
 
 
 
-       When you run [bundle  install(1)][bundle-install(1)]  the  first  time,
+       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:
 
@@ -134,39 +134,40 @@ UPDATING ALL GEMS
        As you can see, even though you have two gems in the  Gemfile(5),  your
        application  needs 26 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)],  bundler  skips the dependency
+       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)] 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.
+       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.
 
 
@@ -178,7 +179,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:
 
 
@@ -196,32 +197,32 @@ 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, by default, when  you	update	a  gem	using  bundle  update,
-       bundler	will update all dependencies of that gem, including those that
+       In  short,  by  default,  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.
 
        To prevent updating shared dependencies, prior to version 1.14 the only
-       option	 was   the   CONSERVATIVE   UPDATING   behavior   in   [bundle
-       install(1)][bundle-install(1)]:
+       option was the CONSERVATIVE UPDATING behavior in bundle install(1) bun-
+       dle-install.1.html:
 
        In this scenario, updating the thin version manually in the Gemfile(5),
-       and  then  running  [bundle  install(1)][bundle-install(1)]  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)].
+       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.
 
        Starting with 1.14, specifying the --conservative option will also pre-
        vent shared dependencies from being updated.
 
 PATCH LEVEL OPTIONS
-       Version	1.14  introduced 4 patch-level options that will influence how
-       gem versions are resolved. One of the following options	can  be  used:
+       Version 1.14 introduced 4 patch-level options that will	influence  how
+       gem  versions  are  resolved. One of the following options can be used:
        --patch, --minor or --major. --strict can be added to further influence
        resolution.
 
@@ -238,41 +239,41 @@ PATCH LEVEL OPTIONS
 	      Do not allow any gem to be updated past latest --patch | --minor
 	      | --major.
 
-       When  Bundler  is  resolving  what  versions to use to satisfy declared
-       requirements in the Gemfile or in parent gems, it looks up  all	avail-
+       When Bundler is resolving what versions	to  use  to  satisfy  declared
+       requirements  in  the Gemfile or in parent gems, it looks up all avail-
        able versions, filters out any versions that don't satisfy the require-
        ment, and then, by default, sorts them from newest to oldest, consider-
        ing them in that order.
 
-       Providing  one  of  the	patch level options (e.g. --patch) changes the
-       sort order of the satisfying versions, causing Bundler to consider  the
+       Providing one of the patch level options  (e.g.	--patch)  changes  the
+       sort  order of the satisfying versions, causing Bundler to consider the
        latest --patch or --minor version available before other versions. Note
        that versions outside the stated patch level could still be resolved to
        if necessary to find a suitable dependency graph.
 
-       For  example,  if gem 'foo' is locked at 1.0.2, with no gem requirement
-       defined in the Gemfile, and versions 1.0.3, 1.0.4, 1.1.0, 1.1.1,  2.0.0
+       For example, if gem 'foo' is locked at 1.0.2, with no  gem  requirement
+       defined	in the Gemfile, and versions 1.0.3, 1.0.4, 1.1.0, 1.1.1, 2.0.0
        all exist, the default order of preference by default (--major) will be
        "2.0.0, 1.1.1, 1.1.0, 1.0.4, 1.0.3, 1.0.2".
 
-       If the --patch option is used, the order of preference will  change  to
+       If  the	--patch option is used, the order of preference will change to
        "1.0.4, 1.0.3, 1.0.2, 1.1.1, 1.1.0, 2.0.0".
 
-       If  the	--minor option is used, the order of preference will change to
+       If the --minor option is used, the order of preference will  change  to
        "1.1.1, 1.1.0, 1.0.4, 1.0.3, 1.0.2, 2.0.0".
 
-       Combining the --strict option with any of the patch level options  will
-       remove  any  versions  beyond  the  scope of the patch level option, to
+       Combining  the --strict option with any of the patch level options will
+       remove any versions beyond the scope of	the  patch  level  option,  to
        ensure that no gem is updated that far.
 
-       To continue the previous example, if both --patch and --strict  options
+       To  continue the previous example, if both --patch and --strict options
        are used, the available versions for resolution would be "1.0.4, 1.0.3,
-       1.0.2". If --minor and --strict are used, it would  be  "1.1.1,	1.1.0,
+       1.0.2".	If  --minor  and --strict are used, it would be "1.1.1, 1.1.0,
        1.0.4, 1.0.3, 1.0.2".
 
-       Gem  requirements  as  defined  in  the Gemfile will still be the first
+       Gem requirements as defined in the Gemfile  will  still	be  the  first
        determining factor for what versions are available. If the gem require-
-       ment  for foo in the Gemfile is '~> 1.0', that will accomplish the same
+       ment for foo in the Gemfile is '~> 1.0', that will accomplish the  same
        thing as providing the --minor and --strict options.
 
 PATCH LEVEL EXAMPLES
@@ -321,26 +322,26 @@ PATCH LEVEL EXAMPLES
 
 
 
-       In case 1, bar is upgraded to 2.1.1, a minor version increase,  because
+       In  case 1, bar is upgraded to 2.1.1, a minor version increase, because
        the dependency from foo 1.4.5 required it.
 
-       In  case  2,  only  foo	is  requested  to be unlocked, but bar is also
-       allowed to move because it's not a declared dependency in the  Gemfile.
+       In case 2, only foo is requested  to  be  unlocked,  but  bar  is  also
+       allowed	to move because it's not a declared dependency in the Gemfile.
 
-       In  case 3, bar goes up a whole major release, because a minor increase
-       is preferred now for foo, and when it goes to 1.5.1, it requires  3.0.0
+       In case 3, bar goes up a whole major release, because a minor  increase
+       is  preferred now for foo, and when it goes to 1.5.1, it requires 3.0.0
        of bar.
 
        In case 4, foo is preferred up to a minor version, but 1.5.1 won't work
-       because the --strict flag removes bar 3.0.0  from  consideration  since
+       because	the  --strict  flag removes bar 3.0.0 from consideration since
        it's a major increment.
 
-       In  case 5, both foo and bar have any minor or major increments removed
-       from consideration because of the --strict flag, so the most  they  can
+       In case 5, both foo and bar have any minor or major increments  removed
+       from  consideration  because of the --strict flag, so the most they can
        move is up to 1.4.4 and 2.0.4.
 
 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
@@ -351,7 +352,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
@@ -360,7 +361,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
@@ -369,12 +370,12 @@ RECOMMENDED WORKFLOW
 
 	   $ git add Gemfile.lock
 
-       o   If [bundle install(1)][bundle-install(1)] reports a conflict, manu-
-	   ally update the specific gems that you changed in the Gemfile(5)
+       o   If bundle install(1) bundle-install.1.html reports a conflict, man-
+	   ually update the specific gems that you changed in the Gemfile(5)
 
 	   $ 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
@@ -384,4 +385,4 @@ RECOMMENDED WORKFLOW
 
 
 
-				   May 2018		      BUNDLE-UPDATE(1)
+				   July 2018		      BUNDLE-UPDATE(1)

data/man/bundle-update.ronn

@@ -20,7 +20,7 @@ bundle-update(1) -- Update your gems to the latest available versions
 
 Update the gems specified (all gems, if none are specified), ignoring
 the previously installed gems specified in the `Gemfile.lock`. In
-general, you should use [bundle install(1)][bundle-install(1)] to install the same exact
+general, 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
@@ -91,7 +91,7 @@ Consider the following Gemfile(5):
     gem "rails", "3.0.0.rc"
     gem "nokogiri"
 
-When you run [bundle install(1)][bundle-install(1)] the first time, bundler will resolve
+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:
 
     Fetching gem metadata from https://rubygems.org/.........
@@ -128,11 +128,11 @@ all of the dependencies, all the way down, and install what you need:
 
 As you can see, even though you have two gems in the Gemfile(5), your application
 needs 26 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)], bundler skips
+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)] will _still_ install the gems that you installed
+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.
 
@@ -192,12 +192,12 @@ update all dependencies of that gem, including those that are also dependencies
 of another gem.
 
 To prevent updating shared dependencies, prior to version 1.14 the only option
-was the `CONSERVATIVE UPDATING` behavior in [bundle install(1)][bundle-install(1)]:
+was the `CONSERVATIVE UPDATING` behavior in [bundle install(1)](bundle-install.1.html):
 
 In this scenario, updating the `thin` version manually in the Gemfile(5),
-and then running [bundle install(1)][bundle-install(1)] will only update `daemons` and `eventmachine`,
+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)][bundle-install(1)].
+of [bundle install(1)](bundle-install.1.html).
 
 Starting with 1.14, specifying the `--conservative` option will also prevent shared
 dependencies from being updated.
@@ -335,7 +335,7 @@ use the following workflow:
 
     $ git add Gemfile.lock
 
-* If [bundle install(1)][bundle-install(1)] reports a conflict, manually update the specific
+* If [bundle install(1)](bundle-install.1.html) reports a conflict, manually update the specific
   gems that you changed in the Gemfile(5)
 
     $ bundle update rails thin

data/man/bundle-viz.1

@@ -1,7 +1,7 @@
 .\" generated with Ronn/v0.7.3
 .\" http://github.com/rtomayko/ronn/tree/0.7.3
 .
-.TH "BUNDLE\-VIZ" "1" "February 2018" "" ""
+.TH "BUNDLE\-VIZ" "1" "July 2018" "" ""
 .
 .SH "NAME"
 \fBbundle\-viz\fR \- Generates a visual dependency graph for your Gemfile
@@ -13,7 +13,7 @@
 \fBviz\fR generates a PNG file of the current \fBGemfile(5)\fR as a dependency graph\. \fBviz\fR requires the ruby\-graphviz gem (and its dependencies)\.
 .
 .P
-The associated gems must also be installed via [\fBbundle install(1)\fR][bundle\-install(1)]\.
+The associated gems must also be installed via \fBbundle install(1)\fR \fIbundle\-install\.1\.html\fR\.
 .
 .SH "OPTIONS"
 .

data/man/bundle-viz.1.txt

@@ -13,8 +13,8 @@ DESCRIPTION
        viz generates a PNG file of the	current  Gemfile(5)  as  a  dependency
        graph. viz requires the ruby-graphviz gem (and its dependencies).
 
-       The associated gems must also be installed via [bundle install(1)][bun-
-       dle-install(1)].
+       The  associated	gems must also be installed via bundle install(1) bun-
+       dle-install.1.html.
 
 OPTIONS
        --file, -f
@@ -36,4 +36,4 @@ OPTIONS
 
 
 
-				 February 2018			 BUNDLE-VIZ(1)
+				   July 2018			 BUNDLE-VIZ(1)

data/man/bundle-viz.ronn

@@ -14,7 +14,7 @@ bundle-viz(1) -- Generates a visual dependency graph for your Gemfile
 `viz` generates a PNG file of the current `Gemfile(5)` as a dependency graph.
 `viz` requires the ruby-graphviz gem (and its dependencies).
 
-The associated gems must also be installed via [`bundle install(1)`][bundle-install(1)].
+The associated gems must also be installed via [`bundle install(1)`](bundle-install.1.html).
 
 ## OPTIONS
 

data/man/bundle.1

@@ -1,7 +1,7 @@
 .\" generated with Ronn/v0.7.3
 .\" http://github.com/rtomayko/ronn/tree/0.7.3
 .
-.TH "BUNDLE" "1" "May 2018" "" ""
+.TH "BUNDLE" "1" "July 2018" "" ""
 .
 .SH "NAME"
 \fBbundle\fR \- Ruby Dependency Management
@@ -35,23 +35,23 @@ We divide \fBbundle\fR subcommands into primary commands and utilities:
 .SH "PRIMARY COMMANDS"
 .
 .TP
-[\fBbundle install(1)\fR][bundle\-install(1)]
+\fBbundle install(1)\fR \fIbundle\-install\.1\.html\fR
 Install the gems specified by the \fBGemfile\fR or \fBGemfile\.lock\fR
 .
 .TP
-[\fBbundle update(1)\fR][bundle\-update(1)]
+\fBbundle update(1)\fR \fIbundle\-update\.1\.html\fR
 Update dependencies to their latest versions
 .
 .TP
-[\fBbundle package(1)\fR][bundle\-package(1)]
+\fBbundle package(1)\fR \fIbundle\-package\.1\.html\fR
 Package the \.gem files required by your application into the \fBvendor/cache\fR directory
 .
 .TP
-[\fBbundle exec(1)\fR][bundle\-exec(1)]
+\fBbundle exec(1)\fR \fIbundle\-exec\.1\.html\fR
 Execute a script in the current bundle
 .
 .TP
-[\fBbundle config(1)\fR][bundle\-config(1)]
+\fBbundle config(1)\fR \fIbundle\-config\.1\.html\fR
 Specify and read configuration options for Bundler
 .
 .TP
@@ -61,23 +61,23 @@ Display detailed help for each subcommand
 .SH "UTILITIES"
 .
 .TP
-[\fBbundle add(1)\fR][bundle\-add(1)]
+\fBbundle add(1)\fR \fIbundle\-add\.1\.html\fR
 Add the named gem to the Gemfile and run \fBbundle install\fR
 .
 .TP
-[\fBbundle binstubs(1)\fR][bundle\-binstubs(1)]
+\fBbundle binstubs(1)\fR \fIbundle\-binstubs\.1\.html\fR
 Generate binstubs for executables in a gem
 .
 .TP
-[\fBbundle check(1)\fR][bundle\-check(1)]
+\fBbundle check(1)\fR \fIbundle\-check\.1\.html\fR
 Determine whether the requirements for your application are installed and available to Bundler
 .
 .TP
-[\fBbundle show(1)\fR][bundle\-show(1)]
+\fBbundle show(1)\fR \fIbundle\-show\.1\.html\fR
 Show the source location of a particular gem in the bundle
 .
 .TP
-[\fBbundle outdated(1)\fR][bundle\-outdated(1)]
+\fBbundle outdated(1)\fR \fIbundle\-outdated\.1\.html\fR
 Show all of the outdated gems in the current bundle
 .
 .TP
@@ -85,35 +85,35 @@ Show all of the outdated gems in the current bundle
 Start an IRB session in the current bundle
 .
 .TP
-[\fBbundle open(1)\fR][bundle\-open(1)]
+\fBbundle open(1)\fR \fIbundle\-open\.1\.html\fR
 Open an installed gem in the editor
 .
 .TP
-[\fBbundle lock(1)\fR][bundle\-lock]
+\fBbundle lock(1)\fR \fIbundle\-lock\.1\.hmtl\fR
 Generate a lockfile for your dependencies
 .
 .TP
-[\fBbundle viz(1)\fR][bundle\-viz(1)]
+\fBbundle viz(1)\fR \fIbundle\-viz\.1\.html\fR
 Generate a visual representation of your dependencies
 .
 .TP
-[\fBbundle init(1)\fR][bundle\-init(1)]
+\fBbundle init(1)\fR \fIbundle\-init\.1\.html\fR
 Generate a simple \fBGemfile\fR, placed in the current directory
 .
 .TP
-[\fBbundle gem(1)\fR][bundle\-gem(1)]
+\fBbundle gem(1)\fR \fIbundle\-gem\.1\.html\fR
 Create a simple gem, suitable for development with Bundler
 .
 .TP
-[\fBbundle platform(1)\fR][bundle\-platform(1)]
+\fBbundle platform(1)\fR \fIbundle\-platform\.1\.html\fR
 Display platform compatibility information
 .
 .TP
-[\fBbundle clean(1)\fR][bundle\-clean(1)]
+\fBbundle clean(1)\fR \fIbundle\-clean\.1\.html\fR
 Clean up unused gems in your Bundler directory
 .
 .TP
-\fBbundle doctor(1)\fR
+\fBbundle doctor(1)\fR \fIbundle\-doctor\.1\.html\fR
 Display warnings about common problems
 .
 .SH "PLUGINS"