bundler 2.1.2 → 2.2.0

data/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.
-
-
-
-
-				 December 2019		      BUNDLE-DOCTOR(1)

data/man/bundle-exec.1.txt

@@ -1,178 +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 [Gem-
-       file(5)][Gemfile(5)]  and  installed   via   bundle   install(1)   bun-
-       dle-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)   bun-
-       dle-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 bun-
-       dle 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  pro-
-	   grams 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 require-
-	   ments 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 lock-
-       file and the Gemfile do not match. Bundler needs the Gemfile to	deter-
-       mine  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  she-
-       bang,  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  optimiza-
-       tion 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  ver-
-       sion  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  Gem-
-       file.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).
-
-
-
-				 December 2019			BUNDLE-EXEC(1)

data/man/bundle-gem.1.txt

@@ -1,91 +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 gen-
-	      erated 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
-	      Specify the test framework that Bundler should use when generat-
-	      ing the project. Acceptable values are minitest and  rspec.  The
-	      GEM_NAME.gemspec	will  be  configured  and a skeleton test/spec
-	      directory will be created based on this option. If  this	option
-	      is  unspecified, an interactive prompt will be displayed and the
-	      answer will be saved in Bundler's global config for future  bun-
-	      dle  gem	use.  If  no  option is specified, the default testing
-	      framework is RSpec.
-
-       -e, --edit[=EDITOR]
-	      Open the resulting GEM_NAME.gemspec in EDITOR,  or  the  default
-	      editor  if  not specified. The default is $BUNDLER_EDITOR, $VIS-
-	      UAL, or $EDITOR.
-
-SEE ALSO
-       o   bundle config(1) bundle-config.1.html
-
-
-
-
-
-
-				 December 2019			 BUNDLE-GEM(1)

data/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
-
-
-
-
-				 December 2019			BUNDLE-INFO(1)

data/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 work-
-       ing 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)][Gem-
-       file(5)].
-
-OPTIONS
-       --gemspec
-	      Use  the	specified  .gemspec  to  create  the [Gemfile(5)][Gem-
-	      file(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
-
-
-
-				 December 2019			BUNDLE-INIT(1)

data/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
-
-
-
-				 December 2019		      BUNDLE-INJECT(1)

data/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...]]]  [--sys-
-       tem]   [--trust-policy=POLICY]	[--with=GROUP[	 GROUP...]]   [--with-
-       out=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	speci-
-       fied 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  cre-
-	      ates  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 applica-
-	      tion needs.
-
-	      Creates a directory (defaults to ~/bin) and places any  executa-
-	      bles from the gem there. These executables run in Bundler's con-
-	      text. If used, you might add this  directory  to	your  environ-
-	      ment'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  pro-
-	      duction  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  Gem-
-	      file.lock.
-
-       --full-index
-	      Bundler will not call Rubygems' API endpoint (default) but down-
-	      load and cache a (currently big) index file of all gems. Perfor-
-	      mance  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  ven-
-	      dor/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	--bin-
-	      stubs  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  bun-
-	      dle/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 Gem-
-	   file.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  loca-
-	   tion
-
-	   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 permis-
-	   sion to read them.
-
-	   As a result, bundle install --deployment installs gems to the  ven-
-	   dor/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	speci-
-       fied  groups, it will still download those gems and use them to resolve
-       the dependencies of every gem in your Gemfile(5).
-
-       This is so that installing a different set of groups on another machine
-       (such  as  a  production  server) will not change the gems and versions
-       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 environ-
-       ments.
-
-       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 appli-
-       cation 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 .git-
-       ignore 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  discour-
-       age  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  activesup-
-       port.  The  actionpack  gem  depends on activesupport 2.3.8 and rack ~>
-       1.1.0, while the activemerchant gem depends on activesupport >=	2.3.2,
-       braintree >= 2.0.0, and builder >= 2.0.0.
-
-       When   the   dependencies  are  first  resolved,  Bundler  will	select
-       activesupport 2.3.8, which satisfies the requirements of both  gems  in
-       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	depen-
-       dency to ~> 1.2.1.
-
-       When  you  run  bundle  install,  Bundler  notices that you changed the
-       actionpack gem, but not the activemerchant gem. It evaluates  the  gems
-       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. How-
-       ever, satisfying the new activesupport 3.0.0.rc dependency  of  action-
-       pack requires updating one of its dependencies.
-
-       Even  though activemerchant declares a very loose dependency that theo-
-       retically matches activesupport 3.0.0.rc, Bundler treats gems  in  your
-       Gemfile(5)  that have not changed as an atomic unit together with their
-       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/
-
-
-
-
-
-
-				 December 2019		     BUNDLE-INSTALL(1)