bundler 1.17.3 → 2.6.3

data/man/bundle-update.1.txt

@@ -1,391 +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]
-       [--force] [--patch|--minor|--major] [--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.
-
-       --force
-	      Force downloading every gem. --redownload is an  alias  of  this
-	      option.
-
-       --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
-
-
-
-
-
-
-				 December 2018		      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.
-
-
-
-
-				 November 2018			 BUNDLE-VIZ(1)

data/man/bundle.1.txt

@@ -1,116 +0,0 @@
-BUNDLE(1)							     BUNDLE(1)
-
-
-
-NAME
-       bundle - Ruby Dependency Management
-
-SYNOPSIS
-       bundle COMMAND [--no-color] [--verbose] [ARGS]
-
-DESCRIPTION
-       Bundler	manages  an application's dependencies through its entire life
-       across many machines systematically and repeatably.
-
-       See the bundler website http://bundler.io for  information  on  getting
-       started, and Gemfile(5) for more information on the Gemfile format.
-
-OPTIONS
-       --no-color
-	      Print all output without color
-
-       --retry, -r
-	      Specify the number of times you wish to attempt network commands
-
-       --verbose, -V
-	      Print out additional logging information
-
-BUNDLE COMMANDS
-       We divide bundle subcommands into primary commands and utilities:
-
-PRIMARY COMMANDS
-       bundle install(1) bundle-install.1.html
-	      Install the gems specified by the Gemfile or Gemfile.lock
-
-       bundle update(1) bundle-update.1.html
-	      Update dependencies to their latest versions
-
-       bundle package(1) bundle-package.1.html
-	      Package the .gem files required by  your	application  into  the
-	      vendor/cache directory
-
-       bundle exec(1) bundle-exec.1.html
-	      Execute a script in the current bundle
-
-       bundle config(1) bundle-config.1.html
-	      Specify and read configuration options for Bundler
-
-       bundle help(1)
-	      Display detailed help for each subcommand
-
-UTILITIES
-       bundle add(1) bundle-add.1.html
-	      Add the named gem to the Gemfile and run bundle install
-
-       bundle binstubs(1) bundle-binstubs.1.html
-	      Generate binstubs for executables in a gem
-
-       bundle check(1) bundle-check.1.html
-	      Determine  whether  the  requirements  for  your application are
-	      installed and available to Bundler
-
-       bundle show(1) bundle-show.1.html
-	      Show the source location of a particular gem in the bundle
-
-       bundle outdated(1) bundle-outdated.1.html
-	      Show all of the outdated gems in the current bundle
-
-       bundle console(1)
-	      Start an IRB session in the current bundle
-
-       bundle open(1) bundle-open.1.html
-	      Open an installed gem in the editor
-
-       bundle lock(1) bundle-lock.1.hmtl
-	      Generate a lockfile for your dependencies
-
-       bundle viz(1) bundle-viz.1.html
-	      Generate a visual representation of your dependencies
-
-       bundle init(1) bundle-init.1.html
-	      Generate a simple Gemfile, placed in the current directory
-
-       bundle gem(1) bundle-gem.1.html
-	      Create a simple gem, suitable for development with Bundler
-
-       bundle platform(1) bundle-platform.1.html
-	      Display platform compatibility information
-
-       bundle clean(1) bundle-clean.1.html
-	      Clean up unused gems in your Bundler directory
-
-       bundle doctor(1) bundle-doctor.1.html
-	      Display warnings about common problems
-
-       bundle remove(1) bundle-remove.1.html
-	      Removes gems from the Gemfile
-
-PLUGINS
-       When running a command that isn't listed in PRIMARY COMMANDS or	UTILI-
-       TIES,  Bundler  will  try  to  find  an	executable  on your path named
-       bundler-<command> and execute it, passing down any extra  arguments  to
-       it.
-
-OBSOLETE
-       These commands are obsolete and should no longer be used:
-
-       o   bundle cache(1)
-
-       o   bundle show(1)
-
-
-
-
-
-
-				 December 2018			     BUNDLE(1)