bundler 2.1.4 → 2.3.12

data/man/bundle-platform.1.txt

@@ -1,57 +0,0 @@
-BUNDLE-PLATFORM(1)					    BUNDLE-PLATFORM(1)
-
-
-
-NAME
-       bundle-platform - Displays platform compatibility information
-
-SYNOPSIS
-       bundle platform [--ruby]
-
-DESCRIPTION
-       platform  will display information from your Gemfile, Gemfile.lock, and
-       Ruby VM about your platform.
-
-       For instance, using this Gemfile(5):
-
-
-
-	   source "https://rubygems.org"
-
-	   ruby "1.9.3"
-
-	   gem "rack"
-
-
-
-       If you run bundle platform on Ruby 1.9.3, it will display the following
-       output:
-
-
-
-	   Your platform is: x86_64-linux
-
-	   Your app has gems that work on these platforms:
-	   * ruby
-
-	   Your Gemfile specifies a Ruby version requirement:
-	   * ruby 1.9.3
-
-	   Your current platform satisfies the Ruby version requirement.
-
-
-
-       platform  will  list  all the platforms in your Gemfile.lock as well as
-       the ruby directive if applicable from your Gemfile(5). It will also let
-       you know if the ruby directive requirement has been met. If ruby direc-
-       tive doesn't match the running Ruby VM, it will tell you what part does
-       not.
-
-OPTIONS
-       --ruby It  will	display  the  ruby directive information, so you don't
-	      have to parse it from the Gemfile(5).
-
-
-
-
-				 January 2020		    BUNDLE-PLATFORM(1)

data/man/bundle-pristine.1.txt

@@ -1,44 +0,0 @@
-BUNDLE-PRISTINE(1)					    BUNDLE-PRISTINE(1)
-
-
-
-NAME
-       bundle-pristine - Restores installed gems to their pristine condition
-
-SYNOPSIS
-       bundle pristine
-
-DESCRIPTION
-       pristine  restores  the	installed gems in the bundle to their pristine
-       condition using the local gem cache from  RubyGems.  For  git  gems,  a
-       forced checkout will be performed.
-
-       For  further  explanation,  bundle  pristine  ignores unpacked files on
-       disk. In other words, this command utilizes the local .gem cache or the
-       gem's git repository as if one were installing from scratch.
-
-       Note:  the  Bundler  gem  cannot be restored to its original state with
-       pristine. One also cannot use bundle pristine on  gems  with  a	'path'
-       option  in  the	Gemfile,  because  bundler has no original copy it can
-       restore from.
-
-       When is it practical to use bundle pristine?
-
-       It comes in handy when a developer is debugging a gem. bundle  pristine
-       is a great way to get rid of experimental changes to a gem that one may
-       not want.
-
-       Why use bundle pristine over gem pristine --all?
-
-       Both commands are very similar. For context: bundle  pristine,  without
-       arguments,  cleans  all gems from the lockfile. Meanwhile, gem pristine
-       --all cleans all installed gems for that Ruby version.
-
-       If a developer forgets which gems in their project they might have been
-       debugging,  the Rubygems gem pristine [GEMNAME] command may be inconve-
-       nient. One can avoid waiting for gem pristine --all,  and  instead  run
-       bundle pristine.
-
-
-
-				 January 2020		    BUNDLE-PRISTINE(1)

data/man/bundle-remove.1.txt

@@ -1,34 +0,0 @@
-BUNDLE-REMOVE(1)					      BUNDLE-REMOVE(1)
-
-
-
-NAME
-       bundle-remove - Removes gems from the Gemfile
-
-SYNOPSIS
-       bundle remove [GEM [GEM ...]] [--install]
-
-DESCRIPTION
-       Removes the given gems from the Gemfile while ensuring that the result-
-       ing Gemfile is still valid. If a gem cannot be removed,	a  warning  is
-       printed.  If  a	gem  is  already absent from the Gemfile, and error is
-       raised.
-
-OPTIONS
-       --install
-	      Runs bundle install after the given gems have been removed  from
-	      the  Gemfile,  which  ensures  that  both  the  lockfile and the
-	      installed gems on disk are also  updated	to  remove  the  given
-	      gem(s).
-
-       Example:
-
-       bundle remove rails
-
-       bundle remove rails rack
-
-       bundle remove rails rack --install
-
-
-
-				 January 2020		      BUNDLE-REMOVE(1)

data/man/bundle-show.1.txt

@@ -1,27 +0,0 @@
-BUNDLE-SHOW(1)							BUNDLE-SHOW(1)
-
-
-
-NAME
-       bundle-show - Shows all the gems in your bundle, or the path to a gem
-
-SYNOPSIS
-       bundle show [GEM] [--paths]
-
-DESCRIPTION
-       Without	the [GEM] option, show will print a list of the names and ver-
-       sions of all gems that are required by  your  [Gemfile(5)][Gemfile(5)],
-       sorted by name.
-
-       Calling	show  with  [GEM]  will list the exact location of that gem on
-       your machine.
-
-OPTIONS
-       --paths
-	      List the paths of all gems  that	are  required  by  your  [Gem-
-	      file(5)][Gemfile(5)], sorted by gem name.
-
-
-
-
-				 January 2020			BUNDLE-SHOW(1)

data/man/bundle-update.1.txt

@@ -1,390 +0,0 @@
-BUNDLE-UPDATE(1)					      BUNDLE-UPDATE(1)
-
-
-
-NAME
-       bundle-update - Update your gems to the latest available versions
-
-SYNOPSIS
-       bundle  update  *gems  [--all] [--group=NAME] [--source=NAME] [--local]
-       [--ruby] [--bundler[=VERSION]] [--full-index]  [--jobs=JOBS]  [--quiet]
-       [--patch|--minor|--major] [--redownload] [--strict] [--conservative]
-
-DESCRIPTION
-       Update  the  gems specified (all gems, if --all flag is used), ignoring
-       the previously installed gems specified in the  Gemfile.lock.  In  gen-
-       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.
-
-OPTIONS
-       --all  Update all gems specified in Gemfile.
-
-       --group=<name>, -g=[<name>]
-	      Only update the gems in the specified group. For	instance,  you
-	      can  update all gems in the development group with bundle update
-	      --group development. You	can  also  call  bundle  update  rails
-	      --group  test  to  update the rails gem and all gems in the test
-	      group, for example.
-
-       --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
-	      --source rails
-
-       --local
-	      Do  not  attempt	to  fetch  gems remotely and use the gem cache
-	      instead.
-
-       --ruby Update the locked version of Ruby  to  the  current  version  of
-	      Ruby.
-
-       --bundler
-	      Update the locked version of bundler to the invoked bundler ver-
-	      sion.
-
-       --full-index
-	      Fall back to using the single-file index of all gems.
-
-       --jobs=[<number>], -j[<number>]
-	      Specify the number of jobs to run in parallel. The default is 1.
-
-       --retry=[<number>]
-	      Retry failed network or git requests for number times.
-
-       --quiet
-	      Only output warnings and errors.
-
-       --redownload
-	      Force downloading every gem.
-
-       --patch
-	      Prefer updating only to next patch version.
-
-       --minor
-	      Prefer updating only to next minor version.
-
-       --major
-	      Prefer updating to next major version (default).
-
-       --strict
-	      Do not allow any gem to be updated past latest --patch | --minor
-	      | --major.
-
-       --conservative
-	      Use bundle install conservative update behavior and do not allow
-	      shared dependencies to be updated.
-
-UPDATING ALL GEMS
-       If you run bundle update --all,	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):
-
-
-
-	   source "https://rubygems.org"
-
-	   gem "rails", "3.0.0.rc"
-	   gem "nokogiri"
-
-
-
-       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/.........
-	   Resolving dependencies...
-	   Installing builder 2.1.2
-	   Installing abstract 1.0.0
-	   Installing rack 1.2.8
-	   Using bundler 1.7.6
-	   Installing rake 10.4.0
-	   Installing polyglot 0.3.5
-	   Installing mime-types 1.25.1
-	   Installing i18n 0.4.2
-	   Installing mini_portile 0.6.1
-	   Installing tzinfo 0.3.42
-	   Installing rack-mount 0.6.14
-	   Installing rack-test 0.5.7
-	   Installing treetop 1.4.15
-	   Installing thor 0.14.6
-	   Installing activesupport 3.0.0.rc
-	   Installing erubis 2.6.6
-	   Installing activemodel 3.0.0.rc
-	   Installing arel 0.4.0
-	   Installing mail 2.2.20
-	   Installing activeresource 3.0.0.rc
-	   Installing actionpack 3.0.0.rc
-	   Installing activerecord 3.0.0.rc
-	   Installing actionmailer 3.0.0.rc
-	   Installing railties 3.0.0.rc
-	   Installing rails 3.0.0.rc
-	   Installing nokogiri 1.6.5
-
-	   Bundle complete! 2 Gemfile dependencies, 26 gems total.
-	   Use `bundle show [gemname]` to see where a bundled gem is installed.
-
-
-
-       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.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
-       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-
-       file(5).
-
-       To do this, run	bundle	update	--all,	which  will  ignore  the  Gem-
-       file.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 --all.
-
-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
-       Gemfile.lock.
-
-       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
-       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
-       thin and rack-perftools-profiler.
-
-
-
-	   source "https://rubygems.org"
-
-	   gem "thin"
-	   gem "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:
-
-
-
-	   Fetching source index for https://rubygems.org/
-	   Installing daemons (1.1.0)
-	   Installing eventmachine (0.12.10) with native extensions
-	   Installing open4 (1.0.1)
-	   Installing perftools.rb (0.4.7) with native extensions
-	   Installing rack (1.2.1)
-	   Installing rack-perftools_profiler (0.0.2)
-	   Installing thin (1.2.7) with native extensions
-	   Using bundler (1.0.0.rc.3)
-
-
-
-       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
-       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
-       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) 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.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:
-       --patch, --minor or --major. --strict can be added to further influence
-       resolution.
-
-       --patch
-	      Prefer updating only to next patch version.
-
-       --minor
-	      Prefer updating only to next minor version.
-
-       --major
-	      Prefer updating to next major version (default).
-
-       --strict
-	      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-
-       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
-       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
-       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
-       "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
-       "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
-       ensure that no gem is updated that far.
-
-       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.4, 1.0.3, 1.0.2".
-
-       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
-       thing as providing the --minor and --strict options.
-
-PATCH LEVEL EXAMPLES
-       Given the following gem specifications:
-
-
-
-	   foo 1.4.3, requires: ~> bar 2.0
-	   foo 1.4.4, requires: ~> bar 2.0
-	   foo 1.4.5, requires: ~> bar 2.1
-	   foo 1.5.0, requires: ~> bar 2.1
-	   foo 1.5.1, requires: ~> bar 3.0
-	   bar with versions 2.0.3, 2.0.4, 2.1.0, 2.1.1, 3.0.0
-
-
-
-       Gemfile:
-
-
-
-	   gem 'foo'
-
-
-
-       Gemfile.lock:
-
-
-
-	   foo (1.4.3)
-	     bar (~> 2.0)
-	   bar (2.0.3)
-
-
-
-       Cases:
-
-
-
-	   #  Command Line		       Result
-	   ------------------------------------------------------------
-	   1  bundle update --patch	       'foo 1.4.5', 'bar 2.1.1'
-	   2  bundle update --patch foo        'foo 1.4.5', 'bar 2.1.1'
-	   3  bundle update --minor	       'foo 1.5.1', 'bar 3.0.0'
-	   4  bundle update --minor --strict   'foo 1.5.0', 'bar 2.1.1'
-	   5  bundle update --patch --strict   'foo 1.4.4', 'bar 2.0.4'
-
-
-
-       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 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
-       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
-       move is up to 1.4.4 and 2.0.4.
-
-RECOMMENDED WORKFLOW
-       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
-
-	   $ bundle install
-
-       o   Check the resulting Gemfile.lock into version control
-
-	   $ git add Gemfile.lock
-
-       o   When checking out this repository on another  development  machine,
-	   run
-
-	   $ bundle install
-
-       o   When checking out this repository on a deployment machine, run
-
-	   $ bundle install --deployment
-
-       o   After  changing  the  Gemfile(5)  to reflect a new or update depen-
-	   dency, run
-
-	   $ bundle install
-
-       o   Make sure to check the updated Gemfile.lock into version control
-
-	   $ git add Gemfile.lock
-
-       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
-	   that still match the gems listed in the Gemfile(5), run
-
-	   $ bundle update --all
-
-
-
-
-
-
-				 January 2020		      BUNDLE-UPDATE(1)

data/man/bundle-viz.1.txt

@@ -1,39 +0,0 @@
-BUNDLE-VIZ(1)							 BUNDLE-VIZ(1)
-
-
-
-NAME
-       bundle-viz - Generates a visual dependency graph for your Gemfile
-
-SYNOPSIS
-       bundle viz [--file=FILE] [--format=FORMAT] [--requirements] [--version]
-       [--without=GROUP GROUP]
-
-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.html.
-
-OPTIONS
-       --file, -f
-	      The name to use for the generated file. See --format option
-
-       --format, -F
-	      This is output format option. Supported format is png, jpg, svg,
-	      dot ...
-
-       --requirements, -R
-	      Set to show the version of each required dependency.
-
-       --version, -v
-	      Set to show each gem version.
-
-       --without, -W
-	      Exclude gems that are part of the specified named group.
-
-
-
-
-				 January 2020			 BUNDLE-VIZ(1)