rubygems-update 3.2.0.rc.1 → 3.2.3

data/bundler/man/bundle-doctor.1.txt

@@ -1,44 +0,0 @@
-BUNDLE-DOCTOR(1)                                              BUNDLE-DOCTOR(1)
-
-
-
-NAME
-       bundle-doctor - Checks the bundle for common problems
-
-SYNOPSIS
-       bundle doctor [--quiet] [--gemfile=GEMFILE]
-
-DESCRIPTION
-       Checks  your Gemfile and gem environment for common problems. If issues
-       are detected, Bundler  prints  them  and  exits  status  1.  Otherwise,
-       Bundler prints a success message and exits status 0.
-
-       Examples of common problems caught by bundle-doctor include:
-
-       o   Invalid Bundler settings
-
-       o   Mismatched Ruby versions
-
-       o   Mismatched platforms
-
-       o   Uninstalled gems
-
-       o   Missing dependencies
-
-
-
-OPTIONS
-       --quiet
-              Only output warnings and errors.
-
-       --gemfile=<gemfile>
-              The  location  of  the Gemfile(5) which Bundler should use. This
-              defaults to a Gemfile(5) in the current  working  directory.  In
-              general, Bundler will assume that the location of the Gemfile(5)
-              is also the project's root and will try to find Gemfile.lock and
-              vendor/cache relative to this location.
-
-
-
-
-                                   July 2020                  BUNDLE-DOCTOR(1)

data/bundler/man/bundle-exec.1.txt

@@ -1,181 +0,0 @@
-BUNDLE-EXEC(1)                                                  BUNDLE-EXEC(1)
-
-
-
-NAME
-       bundle-exec - Execute a command in the context of the bundle
-
-SYNOPSIS
-       bundle exec [--keep-file-descriptors] command
-
-DESCRIPTION
-       This  command  executes  the  command, making all gems specified in the
-       [Gemfile(5)][Gemfile(5)] available to require in Ruby programs.
-
-       Essentially, if you  would  normally  have  run  something  like  rspec
-       spec/my_spec.rb,  and  you  want  to  use  the  gems  specified  in the
-       [Gemfile(5)][Gemfile(5)]   and   installed   via   bundle    install(1)
-       bundle-install.1.html,    you    should    run    bundle   exec   rspec
-       spec/my_spec.rb.
-
-       Note that bundle exec does not require that an executable is  available
-       on your shell's $PATH.
-
-OPTIONS
-       --keep-file-descriptors
-              Exec in Ruby 2.0 began discarding non-standard file descriptors.
-              When this flag is passed, exec will revert to the 1.9  behaviour
-              of passing all file descriptors to the new process.
-
-BUNDLE INSTALL --BINSTUBS
-       If    you    use    the    --binstubs   flag   in   bundle   install(1)
-       bundle-install.1.html, Bundler will automatically  create  a  directory
-       (which  defaults  to  app_root/bin)  containing  all of the executables
-       available from gems in the bundle.
-
-       After using  --binstubs,  bin/rspec  spec/my_spec.rb  is  identical  to
-       bundle exec rspec spec/my_spec.rb.
-
-ENVIRONMENT MODIFICATIONS
-       bundle  exec  makes  a number of changes to the shell environment, then
-       executes the command you specify in full.
-
-       o   make sure that it's still possible to  shell  out  to  bundle  from
-           inside a command invoked by bundle exec (using $BUNDLE_BIN_PATH)
-
-       o   put  the  directory  containing  executables  (like  rails,  rspec,
-           rackup) for your bundle on $PATH
-
-       o   make sure that if bundler is invoked in the subshell, it  uses  the
-           same Gemfile (by setting BUNDLE_GEMFILE)
-
-       o   add  -rbundler/setup  to  $RUBYOPT,  which  makes  sure  that  Ruby
-           programs invoked in the subshell can see the gems in the bundle
-
-
-
-       It also modifies Rubygems:
-
-       o   disallow loading additional gems not in the bundle
-
-       o   modify the gem  method  to  be  a  no-op  if  a  gem  matching  the
-           requirements  is  in  the  bundle, and to raise a Gem::LoadError if
-           it's not
-
-       o   Define Gem.refresh to be a no-op, since the source index is  always
-           frozen  when  using  bundler,  and  to prevent gems from the system
-           leaking into the environment
-
-       o   Override Gem.bin_path to use the gems in the bundle, making  system
-           executables work
-
-       o   Add all gems in the bundle into Gem.loaded_specs
-
-
-
-       Finally,  bundle  exec  also  implicitly  modifies  Gemfile.lock if the
-       lockfile and the Gemfile do not match. Bundler  needs  the  Gemfile  to
-       determine  things  such  as a gem's groups, autorequire, and platforms,
-       etc., and that information isn't stored in the  lockfile.  The  Gemfile
-       and  lockfile  must  be synced in order to bundle exec successfully, so
-       bundle exec updates the lockfile beforehand.
-
-   Loading
-       By default, when attempting to bundle  exec  to  a  file  with  a  ruby
-       shebang,   Bundler   will   Kernel.load  that  file  instead  of  using
-       Kernel.exec. For the vast majority of  cases,  this  is  a  performance
-       improvement.  In  a  rare  few  cases,  this  could  cause  some subtle
-       side-effects (such as  dependence  on  the  exact  contents  of  $0  or
-       __FILE__)  and  the  optimization  can  be  disabled  by  enabling  the
-       disable_exec_load setting.
-
-   Shelling out
-       Any Ruby code that opens a subshell (like system, backticks,  or  %x{})
-       will  automatically use the current Bundler environment. If you need to
-       shell out to a Ruby command that is not part of  your  current  bundle,
-       use  the  with_clean_env  method  with  a  block. Any subshells created
-       inside the block will be given the environment present  before  Bundler
-       was  activated. For example, Homebrew commands run Ruby, but don't work
-       inside a bundle:
-
-
-
-           Bundler.with_clean_env do
-             `brew install wget`
-           end
-
-
-
-       Using with_clean_env is also necessary if you are  shelling  out  to  a
-       different  bundle.  Any Bundler commands run in a subshell will inherit
-       the current Gemfile, so commands that need to run in the context  of  a
-       different bundle also need to use with_clean_env.
-
-
-
-           Bundler.with_clean_env do
-             Dir.chdir "/other/bundler/project" do
-               `bundle exec ./script`
-             end
-           end
-
-
-
-       Bundler  provides  convenience  helpers  that wrap system and exec, and
-       they can be used like this:
-
-
-
-           Bundler.clean_system('brew install wget')
-           Bundler.clean_exec('brew install wget')
-
-
-
-RUBYGEMS PLUGINS
-       At present,  the  Rubygems  plugin  system  requires  all  files  named
-       rubygems_plugin.rb  on the load path of any installed gem when any Ruby
-       code requires rubygems.rb. This includes executables installed into the
-       system, like rails, rackup, and rspec.
-
-       Since  Rubygems  plugins can contain arbitrary Ruby code, they commonly
-       end up activating themselves or their dependencies.
-
-       For instance, the gemcutter 0.5 gem depended on json_pure. If  you  had
-       that  version  of  gemcutter  installed  (even  if you also had a newer
-       version without this problem), Rubygems would  activate  gemcutter  0.5
-       and json_pure <latest>.
-
-       If your Gemfile(5) also contained json_pure (or a gem with a dependency
-       on json_pure), the latest version on your system  might  conflict  with
-       the  version  in  your  Gemfile(5),  or  the  snapshot  version in your
-       Gemfile.lock.
-
-       If this happens, bundler will say:
-
-
-
-           You have already activated json_pure 1.4.6 but your Gemfile
-           requires json_pure 1.4.3. Consider using bundle exec.
-
-
-
-       In this situation, you almost certainly want to remove  the  underlying
-       gem  with  the problematic gem plugin. In general, the authors of these
-       plugins (in this case, the gemcutter gem) have released newer  versions
-       that are more careful in their plugins.
-
-       You can find a list of all the gems containing gem plugins by running
-
-
-
-           ruby -rrubygems -e "puts Gem.find_files('rubygems_plugin.rb')"
-
-
-
-       At the very least, you should remove all but the newest version of each
-       gem plugin, and also remove all gem plugins that you aren't using  (gem
-       uninstall gem_name).
-
-
-
-                                   July 2020                    BUNDLE-EXEC(1)

data/bundler/man/bundle-gem.1.txt

@@ -1,117 +0,0 @@
-BUNDLE-GEM(1)                                                    BUNDLE-GEM(1)
-
-
-
-NAME
-       bundle-gem - Generate a project skeleton for creating a rubygem
-
-SYNOPSIS
-       bundle gem GEM_NAME OPTIONS
-
-DESCRIPTION
-       Generates a directory named GEM_NAME with a Rakefile, GEM_NAME.gemspec,
-       and other supporting files and directories that can be used to  develop
-       a rubygem with that name.
-
-       Run  rake -T in the resulting project for a list of Rake tasks that can
-       be used to test and publish the gem to rubygems.org.
-
-       The generated project skeleton  can  be  customized  with  OPTIONS,  as
-       explained  below.  Note  that  these  options can also be specified via
-       Bundler's global configuration file using the following names:
-
-       o   gem.coc
-
-       o   gem.mit
-
-       o   gem.test
-
-
-
-OPTIONS
-       --exe or -b or --bin
-              Specify that Bundler  should  create  a  binary  executable  (as
-              exe/GEM_NAME) in the generated rubygem project. This binary will
-              also be added to the GEM_NAME.gemspec manifest. This behavior is
-              disabled by default.
-
-       --no-exe
-              Do  not create a binary (overrides --exe specified in the global
-              config).
-
-       --coc  Add a CODE_OF_CONDUCT.md file  to  the  root  of  the  generated
-              project.  If  this  option is unspecified, an interactive prompt
-              will be displayed and the answer  will  be  saved  in  Bundler's
-              global config for future bundle gem use.
-
-       --no-coc
-              Do not create a CODE_OF_CONDUCT.md (overrides --coc specified in
-              the global config).
-
-       --ext  Add boilerplate for C extension code to the  generated  project.
-              This behavior is disabled by default.
-
-       --no-ext
-              Do  not  add  C extension code (overrides --ext specified in the
-              global config).
-
-       --mit  Add an MIT license to a LICENSE.txt file  in  the  root  of  the
-              generated  project. Your name from the global git config is used
-              for the copyright statement. If this option is  unspecified,  an
-              interactive  prompt  will  be  displayed  and the answer will be
-              saved in Bundler's global config for future bundle gem use.
-
-       --no-mit
-              Do not create a LICENSE.txt (overrides --mit  specified  in  the
-              global config).
-
-       -t, --test=minitest, --test=rspec, --test=test-unit
-              Specify   the  test  framework  that  Bundler  should  use  when
-              generating the project. Acceptable values  are  minitest,  rspec
-              and  test-unit.  The  GEM_NAME.gemspec  will be configured and a
-              skeleton test/spec directory  will  be  created  based  on  this
-              option. Given no option is specified:
-
-              When  Bundler  is configured to generate tests, this defaults to
-              Bundler's global config setting gem.test.
-
-              When Bundler is configured to not generate tests, an interactive
-              prompt  will  be  displayed  and the answer will be used for the
-              current rubygem project.
-
-              When Bundler is unconfigured,  an  interactive  prompt  will  be
-              displayed  and  the  answer  will  be  saved in Bundler's global
-              config for future bundle gem use.
-
-       --ci, --ci=github, --ci=travis, --ci=gitlab, --ci=circle
-              Specify the continuous integration service that  Bundler  should
-              use  when  generating the project. Acceptable values are github,
-              travis,  gitlab  and  circle.  A  configuration  file  will   be
-              generated   in   the  project  directory.  Given  no  option  is
-              specified:
-
-              When Bundler is configured to generate CI files,  this  defaults
-              to Bundler's global config setting gem.ci.
-
-              When  Bundler  is  configured  to  not  generate  CI  files,  an
-              interactive prompt will be displayed and the answer will be used
-              for the current rubygem project.
-
-              When  Bundler  is  unconfigured,  an  interactive prompt will be
-              displayed and the answer  will  be  saved  in  Bundler's  global
-              config for future bundle gem use.
-
-       -e, --edit[=EDITOR]
-              Open  the  resulting  GEM_NAME.gemspec in EDITOR, or the default
-              editor  if  not  specified.  The  default  is   $BUNDLER_EDITOR,
-              $VISUAL, or $EDITOR.
-
-SEE ALSO
-       o   bundle config(1) bundle-config.1.html
-
-
-
-
-
-
-                                   July 2020                     BUNDLE-GEM(1)

data/bundler/man/bundle-info.1.txt

@@ -1,21 +0,0 @@
-BUNDLE-INFO(1)                                                  BUNDLE-INFO(1)
-
-
-
-NAME
-       bundle-info - Show information for the given gem in your bundle
-
-SYNOPSIS
-       bundle info [GEM] [--path]
-
-DESCRIPTION
-       Print  the  basic  information about the provided GEM such as homepage,
-       version, path and summary.
-
-OPTIONS
-       --path Print the path of the given gem
-
-
-
-
-                                   July 2020                    BUNDLE-INFO(1)

data/bundler/man/bundle-init.1.txt

@@ -1,34 +0,0 @@
-BUNDLE-INIT(1)                                                  BUNDLE-INIT(1)
-
-
-
-NAME
-       bundle-init - Generates a Gemfile into the current working directory
-
-SYNOPSIS
-       bundle init [--gemspec=FILE]
-
-DESCRIPTION
-       Init  generates  a  default  [Gemfile(5)][Gemfile(5)]  in  the  current
-       working directory. When adding a [Gemfile(5)][Gemfile(5)] to a gem with
-       a  gemspec, the --gemspec option will automatically add each dependency
-       listed    in    the    gemspec    file    to    the    newly    created
-       [Gemfile(5)][Gemfile(5)].
-
-OPTIONS
-       --gemspec
-              Use     the     specified     .gemspec     to     create     the
-              [Gemfile(5)][Gemfile(5)]
-
-FILES
-       Included in the default [Gemfile(5)][Gemfile(5)] generated is the  line
-       #  frozen_string_literal:  true.  This is a magic comment supported for
-       the first time in Ruby 2.3. The presence of this line  results  in  all
-       string literals in the file being implicitly frozen.
-
-SEE ALSO
-       Gemfile(5) https://bundler.io/man/gemfile.5.html
-
-
-
-                                   July 2020                    BUNDLE-INIT(1)

data/bundler/man/bundle-inject.1.txt

@@ -1,32 +0,0 @@
-BUNDLE-INJECT(1)                                              BUNDLE-INJECT(1)
-
-
-
-NAME
-       bundle-inject - Add named gem(s) with version requirements to Gemfile
-
-SYNOPSIS
-       bundle inject [GEM] [VERSION]
-
-DESCRIPTION
-       Adds  the  named gem(s) with their version requirements to the resolved
-       [Gemfile(5)][Gemfile(5)].
-
-       This command will add the gem to both your [Gemfile(5)][Gemfile(5)] and
-       Gemfile.lock if it isn't listed yet.
-
-       Example:
-
-
-
-           bundle install
-           bundle inject 'rack' '> 0'
-
-
-
-       This  will  inject the 'rack' gem with a version greater than 0 in your
-       [Gemfile(5)][Gemfile(5)] and Gemfile.lock
-
-
-
-                                   July 2020                  BUNDLE-INJECT(1)

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

@@ -1,401 +0,0 @@
-BUNDLE-INSTALL(1)                                            BUNDLE-INSTALL(1)
-
-
-
-NAME
-       bundle-install - Install the dependencies specified in your Gemfile
-
-SYNOPSIS
-       bundle   install   [--binstubs[=DIRECTORY]]   [--clean]  [--deployment]
-       [--frozen] [--full-index] [--gemfile=GEMFILE] [--jobs=NUMBER] [--local]
-       [--no-cache]   [--no-prune]   [--path  PATH]  [--quiet]  [--redownload]
-       [--retry=NUMBER]    [--shebang]    [--standalone[=GROUP[    GROUP...]]]
-       [--system]     [--trust-policy=POLICY]     [--with=GROUP[    GROUP...]]
-       [--without=GROUP[ GROUP...]]
-
-DESCRIPTION
-       Install the gems specified in your Gemfile(5). If  this  is  the  first
-       time  you  run  bundle  install  (and  a  Gemfile.lock does not exist),
-       Bundler will fetch all remote sources, resolve dependencies and install
-       all needed gems.
-
-       If a Gemfile.lock does exist, and you have not updated your Gemfile(5),
-       Bundler will  fetch  all  remote  sources,  but  use  the  dependencies
-       specified in the Gemfile.lock instead of resolving dependencies.
-
-       If  a  Gemfile.lock  does  exist, and you have updated your Gemfile(5),
-       Bundler will use the dependencies in the Gemfile.lock for all gems that
-       you  did  not update, but will re-resolve the dependencies of gems that
-       you did update. You can find more information about this update process
-       below under CONSERVATIVE UPDATING.
-
-OPTIONS
-       To  apply  any  of --binstubs, --deployment, --path, or --without every
-       time bundle install is run, use bundle config (see bundle-config(1)).
-
-       --binstubs[=<directory>]
-              Binstubs are  scripts  that  wrap  around  executables.  Bundler
-              creates  a  small Ruby file (a binstub) that loads Bundler, runs
-              the command, and puts it in bin/. This lets you link the binstub
-              inside   of   an  application  to  the  exact  gem  version  the
-              application needs.
-
-              Creates  a  directory  (defaults  to  ~/bin)  and   places   any
-              executables  from  the  gem  there.  These  executables  run  in
-              Bundler's context. If used, you might add this directory to your
-              environment's  PATH  variable.  For  instance,  if the rails gem
-              comes with a rails executable, this flag will create a bin/rails
-              executable  that  ensures that all referred dependencies will be
-              resolved using the bundled gems.
-
-       --clean
-              On finishing the installation Bundler is  going  to  remove  any
-              gems  not  present  in the current Gemfile(5). Don't worry, gems
-              currently in use will not be removed.
-
-       --deployment
-              In deployment mode,  Bundler  will  'roll-out'  the  bundle  for
-              production or CI use. Please check carefully if you want to have
-              this option enabled in your development environment.
-
-       --redownload
-              Force download every gem, even  if  the  required  versions  are
-              already available locally.
-
-       --frozen
-              Do  not allow the Gemfile.lock to be updated after this install.
-              Exits  non-zero  if  there  are  going  to  be  changes  to  the
-              Gemfile.lock.
-
-       --full-index
-              Bundler  will  not  call  Rubygems'  API  endpoint (default) but
-              download and cache a (currently big) index  file  of  all  gems.
-              Performance can be improved for large bundles that seldom change
-              by enabling this option.
-
-       --gemfile=<gemfile>
-              The location of the Gemfile(5) which Bundler  should  use.  This
-              defaults  to  a  Gemfile(5) in the current working directory. In
-              general, Bundler will assume that the location of the Gemfile(5)
-              is also the project's root and will try to find Gemfile.lock and
-              vendor/cache relative to this location.
-
-       --jobs=[<number>], -j[<number>]
-              The maximum number of parallel download and  install  jobs.  The
-              default is 1.
-
-       --local
-              Do not attempt to connect to rubygems.org. Instead, Bundler will
-              use  the  gems  already  present  in  Rubygems'  cache   or   in
-              vendor/cache.  Note  that if a appropriate platform-specific gem
-              exists on rubygems.org it will not be found.
-
-       --no-cache
-              Do not update the cache in vendor/cache with the  newly  bundled
-              gems.  This  does not remove any gems in the cache but keeps the
-              newly bundled gems from being cached during the install.
-
-       --no-prune
-              Don't remove stale gems from the  cache  when  the  installation
-              finishes.
-
-       --path=<path>
-              The  location to install the specified gems to. This defaults to
-              Rubygems' setting. Bundler shares this location  with  Rubygems,
-              gem  install  ... will have gem installed there, too. Therefore,
-              gems installed without a --path ...  setting  will  show  up  by
-              calling gem list. Accordingly, gems installed to other locations
-              will not get listed.
-
-       --quiet
-              Do not  print  progress  information  to  the  standard  output.
-              Instead, Bundler will exit using a status code ($?).
-
-       --retry=[<number>]
-              Retry failed network or git requests for number times.
-
-       --shebang=<ruby-executable>
-              Uses the specified ruby executable (usually ruby) to execute the
-              scripts  created  with  --binstubs.  In  addition,  if  you  use
-              --binstubs  together with --shebang jruby these executables will
-              be changed to execute jruby instead.
-
-       --standalone[=<list>]
-              Makes a bundle that can work without depending  on  Rubygems  or
-              Bundler  at runtime. A space separated list of groups to install
-              has to be specified. Bundler creates a  directory  named  bundle
-              and   installs   the   bundle   there.   It   also  generates  a
-              bundle/bundler/setup.rb file to replace Bundler's own  setup  in
-              the  manner  required.  Using  this option implicitly sets path,
-              which is a [remembered option][REMEMBERED OPTIONS].
-
-       --system
-              Installs the gems  specified  in  the  bundle  to  the  system's
-              Rubygems  location. This overrides any previous configuration of
-              --path.
-
-       --trust-policy=[<policy>]
-              Apply the Rubygems security policy policy, where policy  is  one
-              of  HighSecurity, MediumSecurity, LowSecurity, AlmostNoSecurity,
-              or NoSecurity. For more details, please see the Rubygems signing
-              documentation linked below in SEE ALSO.
-
-       --with=<list>
-              A space-separated list of groups referencing gems to install. If
-              an optional group is given it is installed. If a group is  given
-              that  is in the remembered list of groups given to --without, it
-              is removed from that list.
-
-       --without=<list>
-              A space-separated list of groups referencing gems to skip during
-              installation. If a group is given that is in the remembered list
-              of groups given to --with, it is removed from that list.
-
-DEPLOYMENT MODE
-       Bundler's defaults are optimized for development. To switch to defaults
-       optimized  for deployment and for CI, use the --deployment flag. Do not
-       activate deployment mode on development machines, as it will  cause  an
-       error when the Gemfile(5) is modified.
-
-       1.  A Gemfile.lock is required.
-
-           To ensure that the same versions of the gems you developed with and
-           tested with  are  also  used  in  deployments,  a  Gemfile.lock  is
-           required.
-
-           This   is  mainly  to  ensure  that  you  remember  to  check  your
-           Gemfile.lock into version control.
-
-       2.  The Gemfile.lock must be up to date
-
-           In development, you can modify your Gemfile(5)  and  re-run  bundle
-           install to conservatively update your Gemfile.lock snapshot.
-
-           In  deployment, your Gemfile.lock should be up-to-date with changes
-           made in your Gemfile(5).
-
-       3.  Gems  are  installed  to  vendor/bundle  not  your  default  system
-           location
-
-           In  development,  it's  convenient  to  share the gems used in your
-           application with other applications and other scripts that  run  on
-           the system.
-
-           In  deployment, isolation is a more important default. In addition,
-           the user deploying the  application  may  not  have  permission  to
-           install  gems  to  the  system,  or  the  web  server  may not have
-           permission to read them.
-
-           As a result, bundle  install  --deployment  installs  gems  to  the
-           vendor/bundle  directory in the application. This may be overridden
-           using the --path option.
-
-
-
-SUDO USAGE
-       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
-       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
-       system location.
-
-       From  your  perspective,  this  is  identical  to  installing  the gems
-       directly into the system.
-
-       You should never use sudo bundle install. This is because several other
-       steps in bundle install must be performed as the current user:
-
-       o   Updating your Gemfile.lock
-
-       o   Updating your vendor/cache, if necessary
-
-       o   Checking out private git repositories using your user's SSH keys
-
-
-
-       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  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
-       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
-       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
-       list of groups.
-
-       While the --without  option  will  skip  installing  the  gems  in  the
-       specified  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
-       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
-       different  versions  of  third-party  code  being  used  in   different
-       environments.
-
-       For a simple illustration, consider the following Gemfile(5):
-
-
-
-           source 'https://rubygems.org'
-
-           gem 'sinatra'
-
-           group :production do
-             gem 'rack-perftools-profiler'
-           end
-
-
-
-       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 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
-       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
-       sets of dependencies used in development and production. Because of the
-       vagaries  of  the  dependency  resolution process, this usually affects
-       more than the gems you list in your Gemfile(5), and can  (surprisingly)
-       radically change the gems you are using.
-
-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
-       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
-       application moves across machines.
-
-       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
-       needed to satisfy all dependencies.
-
-       As a result, you SHOULD check your Gemfile.lock into  version  control,
-       in both applications and gems. 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 updated.
-
-       When  Bundler  first  shipped,  the  Gemfile.lock  was  included in the
-       .gitignore file included with generated gems. Over  time,  however,  it
-       became  clear that this practice forces the pain of broken dependencies
-       onto new contributors, while leaving existing contributors  potentially
-       unaware  of the problem. Since bundle install is usually the first step
-       towards  a  contribution,  the  pain  of  broken   dependencies   would
-       discourage  new  contributors  from  contributing. As a result, we have
-       revised our guidance for gem authors to now recommend checking  in  the
-       lock for gems.
-
-CONSERVATIVE UPDATING
-       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
-       of all dependencies as it used before the update.
-
-       Let's take a look at an example. Here's your original Gemfile(5):
-
-
-
-           source 'https://rubygems.org'
-
-           gem 'actionpack', '2.3.8'
-           gem 'activemerchant'
-
-
-
-       In  this  case,  both   actionpack   and   activemerchant   depend   on
-       activesupport.  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
-       your Gemfile(5).
-
-       Next, you modify your Gemfile(5) to:
-
-
-
-           source 'https://rubygems.org'
-
-           gem 'actionpack', '3.0.0.rc'
-           gem 'activemerchant'
-
-
-
-       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
-       dependency 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
-       currently being used to satisfy its requirements:
-
-       activesupport 2.3.8
-              also  used  to  satisfy a dependency in activemerchant, which is
-              not being updated
-
-       rack ~> 1.1.0
-              not currently being used to satisfy another dependency
-
-       Because you did not explicitly ask to update activemerchant, you  would
-       not  expect  it  to  suddenly  stop  working after updating actionpack.
-       However,  satisfying  the  new  activesupport  3.0.0.rc  dependency  of
-       actionpack requires updating one of its dependencies.
-
-       Even  though  activemerchant  declares  a  very  loose  dependency that
-       theoretically 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 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
-       (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 gem in the Gemfile(5) is impacted by the change. If that does not
-       work, run bundle update(1) bundle-update.1.html.
-
-SEE ALSO
-       o   Gem                           install                          docs
-           http://guides.rubygems.org/rubygems-basics/#installing-gems
-
-       o   Rubygems signing docs http://guides.rubygems.org/security/
-
-
-
-
-
-
-                                   July 2020                 BUNDLE-INSTALL(1)