rubygems-update 2.6.4 → 2.6.5

data/bundler/lib/bundler/vendor/thor/lib/thor/version.rb

@@ -0,0 +1,3 @@
+class Bundler::Thor
+  VERSION = "0.19.1"
+end

data/bundler/lib/bundler/vendored_molinillo.rb

@@ -0,0 +1,3 @@
+# frozen_string_literal: true
+module Bundler; end
+require "bundler/vendor/molinillo/lib/molinillo"

data/bundler/lib/bundler/vendored_persistent.rb

@@ -0,0 +1,12 @@
+# frozen_string_literal: true
+# We forcibly require OpenSSL, because net/http/persistent will only autoload
+# it. On some Rubies, autoload fails but explicit require succeeds.
+begin
+  require "openssl"
+rescue LoadError
+  # some Ruby builds don't have OpenSSL
+end
+
+vendor = File.expand_path("../vendor", __FILE__)
+$:.unshift(vendor) unless $:.include?(vendor)
+require "net/http/persistent"

data/bundler/lib/bundler/vendored_thor.rb

@@ -0,0 +1,4 @@
+# frozen_string_literal: true
+module Bundler; end
+require "bundler/vendor/thor/lib/thor"
+require "bundler/vendor/thor/lib/thor/actions"

data/bundler/lib/bundler/version.rb

@@ -0,0 +1,11 @@
+# frozen_string_literal: true
+
+# Ruby 1.9.3 and old RubyGems don't play nice with frozen version strings
+# rubocop:disable MutableConstant
+
+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.13.0.pre.1" unless defined?(::Bundler::VERSION)
+end

data/bundler/lib/bundler/vlad.rb

@@ -0,0 +1,12 @@
+# frozen_string_literal: true
+# Vlad task for Bundler.
+#
+# Add "require 'bundler/vlad'" in your Vlad deploy.rb, and
+# include the vlad:bundle:install task in your vlad:deploy task.
+require "bundler/deployment"
+
+include Rake::DSL if defined? Rake::DSL
+
+namespace :vlad do
+  Bundler::Deployment.define_task(Rake::RemoteTask, :remote_task, :roles => :app)
+end

data/bundler/lib/bundler/worker.rb

@@ -0,0 +1,82 @@
+# frozen_string_literal: true
+require "thread"
+
+module Bundler
+  class Worker
+    POISON = Object.new
+
+    class WrappedException < StandardError
+      attr_reader :exception
+      def initialize(exn)
+        @exception = exn
+      end
+    end
+
+    # @return [String] the name of the worker
+    attr_reader :name
+
+    # Creates a worker pool of specified size
+    #
+    # @param size [Integer] Size of pool
+    # @param name [String] name the name of the worker
+    # @param func [Proc] job to run in inside the worker pool
+    def initialize(size, name, func)
+      @name = name
+      @request_queue = Queue.new
+      @response_queue = Queue.new
+      @func = func
+      @threads = Array.new(size) do |i|
+        Thread.start { process_queue(i) }.tap do |thread|
+          thread.name = "#{name} Worker ##{i}" if thread.respond_to?(:name=)
+        end
+      end
+      trap("INT") { abort_threads }
+    end
+
+    # Enqueue a request to be executed in the worker pool
+    #
+    # @param obj [String] mostly it is name of spec that should be downloaded
+    def enq(obj)
+      @request_queue.enq obj
+    end
+
+    # Retrieves results of job function being executed in worker pool
+    def deq
+      result = @response_queue.deq
+      raise result.exception if result.is_a?(WrappedException)
+      result
+    end
+
+    def stop
+      stop_threads
+    end
+
+  private
+
+    def process_queue(i)
+      loop do
+        obj = @request_queue.deq
+        break if obj.equal? POISON
+        @response_queue.enq apply_func(obj, i)
+      end
+    end
+
+    def apply_func(obj, i)
+      @func.call(obj, i)
+    rescue Exception => e
+      WrappedException.new(e)
+    end
+
+    # Stop the worker threads by sending a poison object down the request queue
+    # so as worker threads after retrieving it, shut themselves down
+    def stop_threads
+      @threads.each { @request_queue.enq POISON }
+      @threads.each(&:join)
+    end
+
+    def abort_threads
+      @threads.each(&:exit)
+      exit 1
+    end
+  end
+end

data/bundler/lib/bundler/yaml_serializer.rb

@@ -0,0 +1,67 @@
+# frozen_string_literal: true
+
+module Bundler
+  # A stub yaml serializer that can handle only hashes and strings (as of now).
+  module YAMLSerializer
+  module_function
+
+    def dump(hash)
+      yaml = String.new("---")
+      yaml << dump_hash(hash)
+    end
+
+    def dump_hash(hash)
+      yaml = String.new("\n")
+      hash.each do |k, v|
+        yaml << k << ":"
+        if v.is_a?(Hash)
+          yaml << dump_hash(v).gsub(/^(?!$)/, "  ") # indent all non-empty lines
+        else
+          yaml << " " << v.to_s.gsub(/\s+/, " ").inspect << "\n"
+        end
+      end
+      yaml
+    end
+
+    SCAN_REGEX = /
+      ^
+      ([ ]*) # indentations
+      (.*) # key
+      (?::(?=\s)) # :  (without the lookahead the #key includes this when : is present in value)
+      [ ]?
+      (?: !\s)? # optional exclamation mark found with ruby 1.9.3
+      (['"]?) # optional opening quote
+      (.*) # value
+      \3 # matching closing quote
+      $
+    /xo
+
+    def load(str)
+      res = {}
+      stack = [res]
+      str.scan(SCAN_REGEX).each do |(indent, key, _, val)|
+        key = convert_to_backward_compatible_key(key)
+        depth = indent.scan(/  /).length
+        if val.empty?
+          new_hash = {}
+          stack[depth][key] = new_hash
+          stack[depth + 1] = new_hash
+        else
+          stack[depth][key] = val
+        end
+      end
+      res
+    end
+
+    # for settings' keys
+    def convert_to_backward_compatible_key(key)
+      key = "#{key}/" if key =~ /https?:/i && key !~ %r{/\Z}
+      key = key.gsub(".", "__") if key.include?(".")
+      key
+    end
+
+    class << self
+      private :dump_hash, :convert_to_backward_compatible_key
+    end
+  end
+end

data/bundler/man/bundle-config.ronn

@@ -0,0 +1,193 @@
+bundle-config(1) -- Set bundler configuration options
+=====================================================
+
+## SYNOPSIS
+
+`bundle config` [<name> [<value>]]
+
+## DESCRIPTION
+
+This command allows you to interact with bundler's configuration system.
+Bundler retrieves its configuration from the local application (`app/.bundle/config`),
+environment variables, and the user's home directory (`~/.bundle/config`),
+in that order of priority.
+
+Executing `bundle config` with no parameters will print a list of all
+bundler configuration for the current bundle, and where that configuration
+was set.
+
+Executing `bundle config <name>` will print the value of that configuration
+setting, and where it was set.
+
+Executing `bundle config <name> <value>` will set that configuration to the
+value specified for all bundles executed as the current user. The configuration
+will be stored in `~/.bundle/config`. If <name> already is set, <name> will be
+overridden and user will be warned.
+
+Executing `bundle config --global <name> <value>` works the same as above.
+
+Executing `bundle config --local <name> <value>` will set that configuration to
+the local application. The configuration will be stored in `app/.bundle/config`.
+
+Executing `bundle config --delete <name>` will delete the configuration in both
+local and global sources. Not compatible with --global or --local flag.
+
+Executing bundle with the `BUNDLE_IGNORE_CONFIG` environment variable set will
+cause it to ignore all configuration.
+
+Executing `bundle config disable_multisource true` upgrades the warning about
+the Gemfile containing multiple primary sources to an error. Executing `bundle
+config --delete disable_multisource` downgrades this error to a warning.
+
+## BUILD OPTIONS
+
+You can use `bundle config` to give bundler the flags to pass to the gem
+installer every time bundler tries to install a particular gem.
+
+A very common example, the `mysql` gem, requires Snow Leopard users to
+pass configuration flags to `gem install` to specify where to find the
+`mysql_config` executable.
+
+    gem install mysql -- --with-mysql-config=/usr/local/mysql/bin/mysql_config
+
+Since the specific location of that executable can change from machine
+to machine, you can specify these flags on a per-machine basis.
+
+    bundle config build.mysql --with-mysql-config=/usr/local/mysql/bin/mysql_config
+
+After running this command, every time bundler needs to install the
+`mysql` gem, it will pass along the flags you specified.
+
+## CONFIGURATION KEYS
+
+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]
+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] remember this setting and skip those
+groups.
+
+The canonical form of this configuration is `"without"`. To convert the canonical
+form to the environment variable form, capitalize it, and prepend `BUNDLE_`. The
+environment variable form of `"without"` is `BUNDLE_WITHOUT`.
+
+Any periods in the configuration keys must be replaced with two underscores when
+setting it via environment variables. The configuration key `local.rack` becomes
+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].
+
+* `path` (`BUNDLE_PATH`):
+  The location on disk where all gems in your bundle will be located regardless
+  of `$GEM_HOME` or `$GEM_PATH` values. Bundle gems not found in this location
+  will be installed by `bundle install`. Defaults to `Gem.dir`. When --deployment is
+  used, defaults to vendor/bundle.
+* `frozen` (`BUNDLE_FROZEN`):
+  Disallow changes to the `Gemfile`. Defaults to `true` when `--deployment`
+  is used.
+* `without` (`BUNDLE_WITHOUT`):
+  A `:`-separated list of groups whose gems bundler should not install
+* `bin` (`BUNDLE_BIN`):
+  Install executables from gems in the bundle to the specified directory.
+  Defaults to `false`.
+* `gemfile` (`BUNDLE_GEMFILE`):
+  The name of the file that bundler should use as the `Gemfile`. This location
+  of this file also sets the root of the project, which is used to resolve
+  relative paths in the `Gemfile`, among other things. By default, bundler
+  will search up from the current working directory until it finds a
+  `Gemfile`.
+* `ssl_ca_cert` (`BUNDLE_SSL_CA_CERT`):
+  Path to a designated CA certificate file or folder containing multiple
+  certificates for trusted CAs in PEM format.
+* `ssl_client_cert` (`BUNDLE_SSL_CLIENT_CERT`):
+  Path to a designated file containing a X.509 client certificate
+  and key in PEM format.
+* `cache_path` (`BUNDLE_CACHE_PATH`): The directory that bundler will place
+  cached gems in when running <code>bundle package</code>, and that bundler
+  will look in when installing gems.
+* `disable_multisource` (`BUNDLE_DISABLE_MULTISOURCE`): When set, Gemfiles
+  containing multiple sources will produce errors instead of warnings. Use
+  `bundle config --delete disable_multisource` to unset.
+* `ignore_messages` (`BUNDLE_IGNORE_MESSAGES`): When set, no post install
+  messages will be printed. To silence a single gem, use dot notation like
+  `ignore_messages.httparty true`.
+* `retry` (`BUNDLE_RETRY`):
+   The number of times to retry failed network requests. Defaults to `3`.
+* `redirect` (`BUNDLE_REDIRECT`):
+   The number of redirects allowed for network requests. Defaults to `5`.
+* `timeout` (`BUNDLE_TIMEOUT`):
+   The seconds allowed before timing out for network requests. Defaults to `10`.
+
+In general, you should set these settings per-application by using the applicable
+flag to the [bundle install(1)][bundle-install] or [bundle package(1)][bundle-package] 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
+will take preference over global settings.
+
+## LOCAL GIT REPOS
+
+Bundler also allows you to work against a git repository locally
+instead of using the remote version. This can be achieved by setting
+up a local override:
+
+    bundle config local.GEM_NAME /path/to/local/git/repository
+
+For example, in order to use a local Rack repository, a developer could call:
+
+    bundle config local.rack ~/Work/git/rack
+
+Now instead of checking out the remote git repository, the local
+override will be used. Similar to a path source, every time the local
+git repository change, changes will be automatically picked up by
+Bundler. This means a commit in the local git repo will update the
+revision in the `Gemfile.lock` to the local git repo revision. This
+requires the same attention as git submodules. Before pushing to
+the remote, you need to ensure the local override was pushed, otherwise
+you may point to a commit that only exists in your local machine.
+
+Bundler does many checks to ensure a developer won't work with
+invalid references. Particularly, we force a developer to specify
+a branch in the `Gemfile` in order to use this feature. If the branch
+specified in the `Gemfile` and the current branch in the local git
+repository do not match, Bundler will abort. This ensures that
+a developer is always working against the correct branches, and prevents
+accidental locking to a different branch.
+
+Finally, Bundler also ensures that the current revision in the
+`Gemfile.lock` exists in the local git repository. By doing this, Bundler
+forces you to fetch the latest changes in the remotes.
+
+## MIRRORS OF GEM SOURCES
+
+Bundler supports overriding gem sources with mirrors. This allows you to
+configure rubygems.org as the gem source in your Gemfile while still using your
+mirror to fetch gems.
+
+    bundle config mirror.SOURCE_URL MIRROR_URL
+
+For example, to use a mirror of rubygems.org hosted at
+
+    bundle config mirror.http://rubygems.org http://rubygems-mirror.org
+
+## CREDENTIALS FOR GEM SOURCES
+
+Bundler allows you to configure credentials for any gem source, which allows
+you to avoid putting secrets into your Gemfile.
+
+    bundle config SOURCE_HOSTNAME USERNAME:PASSWORD
+
+For example, to save the credentials of user `claudette` for the gem source at
+`gems.longerous.com`, you would run:
+
+    bundle config gems.longerous.com claudette:s00pers3krit
+
+Or you can set the credentials as an environment variable like this:
+
+    export BUNDLE_GEMS__LONGEROUS__COM="claudette:s00pers3krit"

data/bundler/man/bundle-exec.ronn

@@ -0,0 +1,136 @@
+bundle-exec(1) -- 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)` 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)` and installed via [bundle install(1)][bundle-install], 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], 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.
+
+* make sure that it's still possible to shell out to `bundle`
+  from inside a command invoked by `bundle exec` (using
+  `$BUNDLE_BIN_PATH`)
+* put the directory containing executables (like `rails`, `rspec`,
+  `rackup`) for your bundle on `$PATH`
+* make sure that if bundler is invoked in the subshell, it uses
+  the same `Gemfile` (by setting `BUNDLE_GEMFILE`)
+* 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:
+
+* disallow loading additional gems not in the bundle
+* 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
+* 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
+* Override `Gem.bin_path` to use the gems in the bundle,
+  making system executables work
+* Add all gems in the bundle into Gem.loaded_specs
+
+### 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 -rubygems -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`).