rubygems-update 2.7.7 → 2.7.8

data/bundler/lib/bundler/vendor/molinillo/lib/molinillo/dependency_graph/vertex.rb

@@ -108,11 +108,21 @@ module Bundler::Molinillo
       # dependency graph?
       # @return true iff there is a path following edges within this {#graph}
       def path_to?(other)
-        equal?(other) || successors.any? { |v| v.path_to?(other) }
+        _path_to?(other)
       end
 
       alias descendent? path_to?
 
+      # @param [Vertex] other the vertex to check if there's a path to
+      # @param [Set<Vertex>] visited the vertices of {#graph} that have been visited
+      # @return [Boolean] whether there is a path to `other` from `self`
+      def _path_to?(other, visited = Set.new)
+        return false unless visited.add?(self)
+        return true if equal?(other)
+        successors.any? { |v| v._path_to?(other, visited) }
+      end
+      protected :_path_to?
+
       # Is there a path from `other` to `self` following edges in the
       # dependency graph?
       # @return true iff there is a path following edges within this {#graph}

data/bundler/lib/bundler/vendor/molinillo/lib/molinillo/errors.rb

@@ -18,7 +18,7 @@ module Bundler::Molinillo
     # @param [Array<Object>] required_by @see {#required_by}
     def initialize(dependency, required_by = [])
       @dependency = dependency
-      @required_by = required_by
+      @required_by = required_by.uniq
       super()
     end
 
@@ -101,9 +101,14 @@ module Bundler::Molinillo
       printable_requirement = opts.delete(:printable_requirement) { proc { |req| req.to_s } }
       additional_message_for_conflict = opts.delete(:additional_message_for_conflict) { proc {} }
       version_for_spec = opts.delete(:version_for_spec) { proc(&:to_s) }
+      incompatible_version_message_for_conflict = opts.delete(:incompatible_version_message_for_conflict) do
+        proc do |name, _conflict|
+          %(#{solver_name} could not find compatible versions for #{possibility_type} "#{name}":)
+        end
+      end
 
       conflicts.sort.reduce(''.dup) do |o, (name, conflict)|
-        o << %(\n#{solver_name} could not find compatible versions for #{possibility_type} "#{name}":\n)
+        o << "\n" << incompatible_version_message_for_conflict.call(name, conflict) << "\n"
         if conflict.locked_requirement
           o << %(  In snapshot (#{name_for_locking_dependency_source}):\n)
           o << %(    #{printable_requirement.call(conflict.locked_requirement)}\n)

data/bundler/lib/bundler/vendor/molinillo/lib/molinillo/gem_metadata.rb

@@ -2,5 +2,5 @@
 
 module Bundler::Molinillo
   # The version of Bundler::Molinillo.
-  VERSION = '0.6.4'.freeze
+  VERSION = '0.6.6'.freeze
 end

data/bundler/lib/bundler/version.rb

@@ -7,7 +7,7 @@ module Bundler
   # We're doing this because we might write tests that deal
   # with other versions of bundler and we are unsure how to
   # handle this better.
-  VERSION = "1.16.2" unless defined?(::Bundler::VERSION)
+  VERSION = "1.16.6" unless defined?(::Bundler::VERSION)
 
   def self.overwrite_loaded_gem_version
     begin

data/bundler/man/bundle-binstubs.ronn

@@ -40,4 +40,4 @@ Calling binstubs with [GEM [GEM]] will create binstubs for all given gems.
 ## BUNDLE INSTALL --BINSTUBS
 
 To create binstubs for all the gems in the bundle you can use the `--binstubs`
-flag in [bundle install(1)][bundle-install(1)].
+flag in [bundle install(1)](bundle-install.1.html).

data/bundler/man/bundle-config.ronn

@@ -102,11 +102,11 @@ After running this command, every time bundler needs to install the
 Configuration keys in bundler have two forms: the canonical form and the
 environment variable form.
 
-For instance, passing the `--without` flag to [bundle install(1)][bundle-install(1)]
+For instance, passing the `--without` flag to [bundle install(1)](bundle-install.1.html)
 prevents Bundler from installing certain groups specified in the Gemfile(5). Bundler
 persists this value in `app/.bundle/config` so that calls to `Bundler.setup`
 do not try to find gems from the `Gemfile` that you didn't install. Additionally,
-subsequent calls to [bundle install(1)][bundle-install(1)] remember this setting
+subsequent calls to [bundle install(1)](bundle-install.1.html) remember this setting
 and skip those groups.
 
 The canonical form of this configuration is `"without"`. To convert the canonical
@@ -120,7 +120,7 @@ the environment variable `BUNDLE_LOCAL__RACK`.
 ## LIST OF AVAILABLE KEYS
 
 The following is a list of all configuration keys and their purpose. You can
-learn more about their operation in [bundle install(1)][bundle-install(1)].
+learn more about their operation in [bundle install(1)](bundle-install.1.html).
 
 * `allow_bundler_dependency_conflicts` (`BUNDLE_ALLOW_BUNDLER_DEPENDENCY_CONFLICTS`):
    Allow resolving to specifications that have dependencies on `bundler` that
@@ -281,7 +281,7 @@ learn more about their operation in [bundle install(1)][bundle-install(1)].
    A `:`-separated list of groups whose gems bundler should not install.
 
 In general, you should set these settings per-application by using the applicable
-flag to the [bundle install(1)][bundle-install(1)] or [bundle package(1)][bundle-package(1)] command.
+flag to the [bundle install(1)](bundle-install.1.html) or [bundle package(1)](bundle-package.1.html) command.
 
 You can set them globally either via environment variables or `bundle config`,
 whichever is preferable for your setup. If you use both, environment variables

data/bundler/man/bundle-exec.ronn

@@ -12,7 +12,7 @@ This command executes the command, making all gems specified in the
 
 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)], you
+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
@@ -27,7 +27,7 @@ available on your shell's `$PATH`.
 
 ## BUNDLE INSTALL --BINSTUBS
 
-If you use the `--binstubs` flag in [bundle install(1)][bundle-install(1)], Bundler will
+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.
 

data/bundler/man/bundle-gem.ronn

@@ -75,4 +75,4 @@ configuration file using the following names:
 
 ## SEE ALSO
 
-* [bundle config(1)][bundle-config(1)]
+* [bundle config(1)](bundle-config.1.html)

data/bundler/man/bundle-install.ronn

@@ -290,12 +290,21 @@ 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. If you do not, every machine that checks out your
-repository (including your production server) will resolve all
+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`,
@@ -361,7 +370,7 @@ which other gems in the Gemfile(5) still depend on, run
 `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)].
+does not work, run [bundle update(1)](bundle-update.1.html).
 
 ## SEE ALSO
 

data/bundler/man/bundle-lock.ronn

@@ -91,4 +91,4 @@ For a full explanation of gem platforms, see `gem help platform`.
 
 ## PATCH LEVEL OPTIONS
 
-See [bundle update(1)][bundle-update(1)] for details.
+See [bundle update(1)](bundle-update.1.html) for details.

data/bundler/man/bundle-outdated.ronn

@@ -69,7 +69,7 @@ are up to date, Bundler will exit with a status of 0. Otherwise, it will exit 1.
 
 ## PATCH LEVEL OPTIONS
 
-See [bundle update(1)][bundle-update(1)] for details.
+See [bundle update(1)](bundle-update.1.html) for details.
 
 One difference between the patch level options in `bundle update` and here is the `--strict` option.
 `--strict` was already an option on outdated before the patch level options were added. `--strict`

data/bundler/man/bundle-package.ronn

@@ -27,8 +27,8 @@ in your local bundler configuration.
 
 ## REMOTE FETCHING
 
-By default, if you run `bundle install(1)`][bundle-install(1)] after running
-[bundle package(1)][bundle-package(1)], bundler will still connect to `rubygems.org`
+By default, if you run `bundle install(1)`](bundle-install.1.html) after running
+[bundle package(1)](bundle-package.1.html), bundler will still connect to `rubygems.org`
 to check whether a platform-specific gem exists for any of the gems
 in `vendor/cache`.
 
@@ -66,7 +66,7 @@ machine and check in the gems. For instance, you can run
 staging process, and check in the `vendor/cache` before
 deploying to production.
 
-By default, [bundle package(1)][bundle-package(1)] fetches and also
+By default, [bundle package(1)](bundle-package.1.html) fetches and also
 installs the gems to the default location. To package the
 dependencies to `vendor/cache` without installing them to the
 local install location, you can run `bundle package --no-install`.

data/bundler/man/bundle-show.ronn

@@ -9,7 +9,7 @@ bundle-show(1) -- Shows all the gems in your bundle, or the path to a gem
 ## DESCRIPTION
 
 Without the [GEM] option, `show` will print a list of the names and versions of
-all gems that are required by your [`Gemfile(5)`][Gemfile(5)].
+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.
@@ -17,4 +17,5 @@ machine.
 ## OPTIONS
 
 * `--paths`:
-  List the paths of all gems that are required by your [`Gemfile(5)`][Gemfile(5)].
+  List the paths of all gems that are required by your [`Gemfile(5)`][Gemfile(5)],
+  sorted by gem name.

data/bundler/man/bundle-update.ronn

@@ -3,7 +3,8 @@ bundle-update(1) -- Update your gems to the latest available versions
 
 ## SYNOPSIS
 
-`bundle update` <*gems> [--group=NAME]
+`bundle update` <*gems> [--all]
+                        [--group=NAME]
                         [--source=NAME]
                         [--local]
                         [--ruby]
@@ -18,9 +19,9 @@ bundle-update(1) -- Update your gems to the latest available versions
 
 ## DESCRIPTION
 
-Update the gems specified (all gems, if none are specified), ignoring
+Update the gems specified (all gems, if `--all` flag is used), ignoring
 the previously installed gems specified in the `Gemfile.lock`. In
-general, you should use [bundle install(1)][bundle-install(1)] to install the same exact
+general, you should use [bundle install(1)](bundle-install.1.html) to install the same exact
 gems and versions across machines.
 
 You would use `bundle update` to explicitly update the version of a
@@ -28,6 +29,9 @@ 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
@@ -80,7 +84,7 @@ gem.
 
 ## UPDATING ALL GEMS
 
-If you run `bundle update` with no parameters, bundler will ignore
+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.
 
@@ -91,7 +95,7 @@ Consider the following Gemfile(5):
     gem "rails", "3.0.0.rc"
     gem "nokogiri"
 
-When you run [bundle install(1)][bundle-install(1)] the first time, bundler will resolve
+When you run [bundle install(1)](bundle-install.1.html) the first time, bundler will resolve
 all of the dependencies, all the way down, and install what you need:
 
     Fetching gem metadata from https://rubygems.org/.........
@@ -128,21 +132,21 @@ all of the dependencies, all the way down, and install what you need:
 
 As you can see, even though you have two gems in the Gemfile(5), your application
 needs 26 different gems in order to run. Bundler remembers the exact versions
-it installed in `Gemfile.lock`. The next time you run [bundle install(1)][bundle-install(1)], bundler skips
+it installed in `Gemfile.lock`. The next time you run [bundle install(1)](bundle-install.1.html), bundler skips
 the dependency resolution and installs the same gems as it installed last time.
 
 After checking in the `Gemfile.lock` into version control and cloning it on another
-machine, running [bundle install(1)][bundle-install(1)] will _still_ install the gems that you installed
+machine, running [bundle install(1)](bundle-install.1.html) will _still_ install the gems that you installed
 last time. You don't need to worry that a new release of `erubis` or `mail` changes
 the gems you use.
 
 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 Gemfile(5).
 
-To do this, run `bundle update`, which will ignore the `Gemfile.lock`, and resolve
+To do this, run `bundle update --all`, which will ignore the `Gemfile.lock`, and resolve
 all the dependencies again. Keep in mind that this process can result in a significantly
 different set of the 25 gems, based on the requirements of new gems that the gem
-authors released since the last time you ran `bundle update`.
+authors released since the last time you ran `bundle update --all`.
 
 ## UPDATING A LIST OF GEMS
 
@@ -192,12 +196,12 @@ update all dependencies of that gem, including those that are also dependencies
 of another gem.
 
 To prevent updating shared dependencies, prior to version 1.14 the only option
-was the `CONSERVATIVE UPDATING` behavior in [bundle install(1)][bundle-install(1)]:
+was the `CONSERVATIVE UPDATING` behavior in [bundle install(1)](bundle-install.1.html):
 
 In this scenario, updating the `thin` version manually in the Gemfile(5),
-and then running [bundle install(1)][bundle-install(1)] will only update `daemons` and `eventmachine`,
+and then running [bundle install(1)](bundle-install.1.html) will only update `daemons` and `eventmachine`,
 but not `rack`. For more information, see the `CONSERVATIVE UPDATING` section
-of [bundle install(1)][bundle-install(1)].
+of [bundle install(1)](bundle-install.1.html).
 
 Starting with 1.14, specifying the `--conservative` option will also prevent shared
 dependencies from being updated.
@@ -335,7 +339,7 @@ use the following workflow:
 
     $ git add Gemfile.lock
 
-* If [bundle install(1)][bundle-install(1)] reports a conflict, manually update the specific
+* If [bundle install(1)](bundle-install.1.html) reports a conflict, manually update the specific
   gems that you changed in the Gemfile(5)
 
     $ bundle update rails thin
@@ -343,4 +347,4 @@ use the following workflow:
 * 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
+    $ bundle update --all

data/bundler/man/bundle-viz.ronn

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

data/bundler/man/bundle.ronn

@@ -30,20 +30,20 @@ We divide `bundle` subcommands into primary commands and utilities:
 
 ## PRIMARY COMMANDS
 
-* [`bundle install(1)`][bundle-install(1)]:
+* [`bundle install(1)`](bundle-install.1.html):
   Install the gems specified by the `Gemfile` or `Gemfile.lock`
 
-* [`bundle update(1)`][bundle-update(1)]:
+* [`bundle update(1)`](bundle-update.1.html):
   Update dependencies to their latest versions
 
-* [`bundle package(1)`][bundle-package(1)]:
+* [`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)]:
+* [`bundle exec(1)`](bundle-exec.1.html):
   Execute a script in the current bundle
 
-* [`bundle config(1)`][bundle-config(1)]:
+* [`bundle config(1)`](bundle-config.1.html):
   Specify and read configuration options for Bundler
 
 * `bundle help(1)`:
@@ -51,47 +51,47 @@ We divide `bundle` subcommands into primary commands and utilities:
 
 ## UTILITIES
 
-* [`bundle add(1)`][bundle-add(1)]:
+* [`bundle add(1)`](bundle-add.1.html):
   Add the named gem to the Gemfile and run `bundle install`
 
-* [`bundle binstubs(1)`][bundle-binstubs(1)]:
+* [`bundle binstubs(1)`](bundle-binstubs.1.html):
   Generate binstubs for executables in a gem
 
-* [`bundle check(1)`][bundle-check(1)]:
+* [`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)]:
+* [`bundle show(1)`](bundle-show.1.html):
   Show the source location of a particular gem in the bundle
 
-* [`bundle outdated(1)`][bundle-outdated(1)]:
+* [`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)]:
+* [`bundle open(1)`](bundle-open.1.html):
   Open an installed gem in the editor
 
-* [`bundle lock(1)`][bundle-lock]:
+* [`bundle lock(1)`](bundle-lock.1.hmtl):
   Generate a lockfile for your dependencies
 
-* [`bundle viz(1)`][bundle-viz(1)]:
+* [`bundle viz(1)`](bundle-viz.1.html):
   Generate a visual representation of your dependencies
 
-* [`bundle init(1)`][bundle-init(1)]:
+* [`bundle init(1)`](bundle-init.1.html):
   Generate a simple `Gemfile`, placed in the current directory
 
-* [`bundle gem(1)`][bundle-gem(1)]:
+* [`bundle gem(1)`](bundle-gem.1.html):
   Create a simple gem, suitable for development with Bundler
 
-* [`bundle platform(1)`][bundle-platform(1)]:
+* [`bundle platform(1)`](bundle-platform.1.html):
   Display platform compatibility information
 
-* [`bundle clean(1)`][bundle-clean(1)]:
+* [`bundle clean(1)`](bundle-clean.1.html):
   Clean up unused gems in your Bundler directory
 
-* `bundle doctor(1)`:
+* [`bundle doctor(1)`](bundle-doctor.1.html):
   Display warnings about common problems
 
 ## PLUGINS

data/bundler/man/gemfile.5.ronn

@@ -35,7 +35,7 @@ this warning, by using the [`:source` option](#SOURCE) or a
 
 ### CREDENTIALS
 
-Some gem sources require a username and password. Use [bundle config(1)][bundle-config(1)] to set
+Some gem sources require a username and password. Use [bundle config(1)](bundle-config.1.html) to set
 the username and password for any of the sources that need it. The command must
 be run once on each computer that will install the Gemfile, but this keeps the
 credentials from being stored in plain text in version control.
@@ -59,8 +59,8 @@ All parameters are `OPTIONAL` unless otherwise specified.
 ### VERSION (required)
 
 The version of Ruby that your application requires. If your application
-requires an alternate Ruby engine, such as JRuby or Rubinius, this should be
-the Ruby version that the engine is compatible with.
+requires an alternate Ruby engine, such as JRuby, Rubinius or TruffleRuby, this
+should be the Ruby version that the engine is compatible with.
 
     ruby "1.9.3"
 
@@ -188,22 +188,24 @@ platforms.
 There are a number of `Gemfile` platforms:
 
   * `ruby`:
-    C Ruby (MRI) or Rubinius, but `NOT` Windows
+    C Ruby (MRI), Rubinius or TruffleRuby, but `NOT` Windows
   * `mri`:
-    Same as _ruby_, but not Rubinius
+    Same as _ruby_, but only C Ruby (MRI)
   * `mingw`:
     Windows 32 bit 'mingw32' platform (aka RubyInstaller)
   * `x64_mingw`:
     Windows 64 bit 'mingw32' platform (aka RubyInstaller x64)
   * `rbx`:
-    Same as _ruby_, but only Rubinius (not MRI)
+    Rubinius
   * `jruby`:
     JRuby
+  * `truffleruby`:
+    TruffleRuby
   * `mswin`:
     Windows
 
 You can restrict further by platform and version for all platforms *except* for
-`rbx`, `jruby`, and `mswin`.
+`rbx`, `jruby`, `truffleruby` and `mswin`.
 
 To specify a version in addition to a platform, append the version number without
 the delimiter to the platform. For example, to specify that a gem should only be
@@ -228,7 +230,7 @@ As with groups, you can specify one or more platforms:
     gem "ruby-debug", :platforms => :mri_18
     gem "nokogiri",   :platforms => [:mri_18, :jruby]
 
-All operations involving groups ([`bundle install`][bundle-install(1)], `Bundler.setup`,
+All operations involving groups ([`bundle install`](bundle-install.1.html), `Bundler.setup`,
 `Bundler.require`) behave exactly the same as if any groups not
 matching the current platform were explicitly excluded.
 
@@ -251,6 +253,12 @@ Selecting a specific source repository this way also suppresses the ambiguous
 gem warning described above in
 [GLOBAL SOURCES (#source)](#GLOBAL-SOURCES).
 
+Using the `:source` option for an individual gem will also make that source
+available as a possible global source for any other gems which do not specify
+explicit sources. Thus, when adding gems with explicit sources, it is
+recommended that you also ensure all other gems in the Gemfile are using
+explicit sources.
+
 ### GIT
 
 If necessary, you can specify that a gem is located at a particular
@@ -453,6 +461,13 @@ In the case of the `git` block form, the `:ref`, `:branch`, `:tag`,
 and `:submodules` options may be passed to the `git` method, and
 all gems in the block will inherit those options.
 
+The presence of a `source` block in a Gemfile also makes that source
+available as a possible global source for any other gems which do not specify
+explicit sources. Thus, when defining source blocks, it is
+recommended that you also ensure all other gems in the Gemfile are using
+explicit sources, either via source blocks or `:source` directives on
+individual gems.
+
 ## INSTALL_IF
 
 The `install_if` method allows gems to be installed based on a proc or lambda.