rubygems-update 3.5.3 → 3.7.1

data/doc/rubygems/CONTRIBUTING.md

@@ -0,0 +1,227 @@
+# How to contribute
+
+Community involvement is essential to RubyGems. We want to keep it as easy as
+possible to contribute changes. There are a few guidelines that we need
+contributors to follow to reduce the time it takes to get changes merged in.
+
+## Guidelines
+
+1.  New features should be coupled with tests.
+
+2.  Ensure that your code blends well with ours:
+    *   No trailing whitespace
+    *   Match indentation (two spaces)
+    *   Match coding style (run `bin/rake rubocop`)
+
+3.  If any new files are added or existing files removed in a commit or PR,
+    please update the `Manifest.txt` accordingly. This can be done by running
+    `bin/rake update_manifest`
+
+4.  Don't modify the history file or version number.
+
+5.  If you have any questions, Feel free to join us on Slack, you can register
+    by signing up at http://slack.bundler.io or file an issue here:
+    http://github.com/rubygems/rubygems/issues
+
+
+For more information and ideas on how to contribute to RubyGems ecosystem, see
+here: https://guides.rubygems.org/contributing/
+
+## Getting Started
+
+### Installing dependencies
+
+    bin/rake setup
+
+> **NOTE**: If the above fails with permission related errors, you're most
+> likely using a global Ruby installation (like the one packaged by your OS),
+> which sets `GEM_HOME` to a location regular users can't write to. Consider
+> using a Ruby version manager like [RVM](https://github.com/rvm/rvm),
+> [rbenv](https://github.com/rbenv/rbenv),
+> [chruby](https://github.com/postmodern/chruby) or [asdf](https://github.com/asdf-vm/asdf-ruby). These will install Ruby to a
+> location regular users can write to, so you won't run into permission issues.
+> Alternatively, consider setting `GEM_HOME` environment variable to a writable
+> location with something like `export GEM_HOME=/tmp/rubygems.gems` and try
+> again.
+
+### Manually trying your local changes
+
+To run commands like `gem install` from the repo:
+
+    ruby -Ilib exe/gem install
+
+To run commands like `bundle install` from the repo:
+
+    bundler/bin/bundle install
+
+### Running Tests
+
+To run the entire test suite you can use:
+
+    bin/rake test
+
+To run an individual test file located for example in `test/rubygems/test_deprecate.rb` you can use:
+
+    ruby -Ilib:test:bundler/lib test/rubygems/test_deprecate.rb
+
+And to run an individual test method named `test_default` within a test file, you can use:
+
+    ruby -Ilib:test:bundler/lib test/rubygems/test_deprecate.rb -n /test_default/
+
+### Running bundler tests
+
+To run the entire bundler test suite in parallel (it takes a while), run the following from the `bundler/` subfolder:
+
+    bin/parallel_rspec
+
+There are some realworld higher level specs run in CI, but not run by `bin/parallel_rspec`. You can run those with:
+
+    bin/rake spec:realworld
+
+To run an individual test file location for example in `spec/install/gems/standalone_spec.rb` you can use the following from the `bundler/` subfolder:
+
+    bin/rspec spec/install/gems/standalone_spec.rb
+
+### Checking code style
+
+You can check compliance with our code style with
+
+    bin/rake rubocop
+
+Optionally you can configure git hooks with to check this before every commit with
+
+    bin/rake git_hooks
+
+For more information, check [SETUP.md](../bundler/development/SETUP.md) and [DEBUGGING.md](../bundler/development/DEBUGGING.md).
+
+## Issues
+
+RubyGems uses labels to track all issues and pull requests. In order to
+provide guidance to the community this is documentation of how labels are used
+in the rubygems repository.
+
+### Contribution
+
+These labels are made to guide contributors to issue/pull requests that they
+can help with.
+
+*   **good first issue** - The issue described here is considered a good option
+    for a new contributor. We encourage new contributors though to work on
+    whichever issue they find most interesting, the ones labeled here as just
+    estimated to have a reasonable level of complexity for someone new to the
+    code base.
+*   **help wanted** - The issue has not been claimed for work, and is awaiting
+    willing volunteers!
+
+
+### Type
+
+Issues might have a light green `type: *` label,  which describes the type of
+the issue.
+
+*   **bug report** - An issue describing a bug in rubygems. This would be
+    something that is broken, confusing, unexpected behavior etc.
+*   **feature request** - An issue describing a request for a new feature or
+    enhancement.
+*   **question** - An issue that is a more of a question than a call for
+    specific changes in the codebase.
+*   **cleanup** - An issue that proposes cleanups to the code base without
+    fixing a bug or implementing a feature.
+*   **major bump** - This issue  request requires a major version bump
+*   **administrative** - This issue relates to administrative tasks that need
+    to take place as it relates to rubygems
+*   **documentation** - This issue relates to improving the documentation for
+    in this repo. Note that much of the rubygems documentation is here:
+    https://github.com/rubygems/guides
+
+Pull request might have a light orange `rubygems: *` or a light blue `bundler:
+*` label which describes the pull request according to the following criteria:
+
+*   **security fix** - A pull request that fixes a security issue.
+*   **breaking change** - A pull request including any change that requires a
+    major version bump.
+*   **major enhancement** - A pull request including a backwards compatible
+    change worth a special mention in the changelog
+*   **deprecation** - A pull request that introduces a deprecation.
+*   **feature** - A pull request implementing a feature request.
+*   **deprecation** - A pull request that implements a performance improvement.
+*   **documentation** - A pull request introducing documentation improvements
+    worth mentioning to end users.
+*   **minor enhancements** - A pull request introducing small but user visible changes.
+*   **bug fix** - A pull request that fixes a bug report.
+
+In the case of `bundler`, these labels are set by maintainers on PRs and have
+special importance because they are used to automatically build the changelog.
+
+### Workflow / Status
+
+The light yellow `status: *` labels that indicate the state of an  issue,
+where it is in the process from being submitted to being closed.  These are
+listed in rough  progression order from submitted to closed.
+
+*   **triage** - This is an issue or pull request that needs to be properly
+    labeled by a maintainer.
+*   **confirmed** - This issue/pull request has been accepted as valid, but is
+    not yet immediately ready for work.
+*   **ready** - An issue that is available for collaboration. This issue
+    should have existing discussion on the problem, and a description of how
+    to go about solving it.
+*   **working** - An issue that has a specific individual assigned to and
+    planning to do work on it.
+*   **user feedback required** - The issue/pull request is blocked pending
+    more feedback from an end user
+*   **blocked / backlog** - the issue/pull request is currently unable to move
+    forward because of some specific reason, generally this will be a reason
+    that is outside RubyGems or needs feedback from some specific individual
+    or group, and it may be a while before something it is resolved.
+
+
+### Closed Reason
+
+Reasons are why an issue / pull request was closed without being worked on or
+accepted. There should also be more detailed information in the comments. The
+closed reason labels are maroon `closed: *`.
+
+*   **duplicate** - This is a duplicate of an existing bug. The comments must
+    reference the existing issue.
+*   **abandoned** - This is an issue/pull request that has aged off, is no
+    longer applicable or similar.
+*   **declined** - An issue that won't be fixed/implemented or a pull request
+    that is not accepted.
+*   **deprecated** - An issue/pull request that no longer applies to the
+    actively maintained codebase.
+*   **discussion** - An issue/pull that is no longer about a concrete change,
+    and is instead being used for discussion.
+
+
+### Categories
+
+These are aspects of the codebase, or what general area the issue or pull
+request pertains too. Not all issues will have a category. All categorized
+issues have a blue `category: *` label.
+
+*   **gemspec** - related to the gem specification itself
+*   **API** - related to the public supported rubygems API. This is the code
+    API, not a network related API.
+*   **command** - related to something in `Gem::Commands`
+*   **install** - related to gem installations
+*   **documentation** - related to updating / fixing / clarifying
+    documentation or guides
+
+
+### Platforms
+
+If an issue or pull request pertains to only one platform, then it should have
+an appropriate purple `platform: *` label. Current platform labels:
+**windows**, **java**, **osx**, **linux**
+
+### Git
+
+Please sign your commits. Although not required in order for you to contribute,
+it ensures that any code submitted by you wasn't altered while you were
+transferring it, and proves that it was you who submitted it and not someone
+else.
+
+Please see https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work or
+https://help.github.com/en/articles/signing-commits for details on how to
+to generate a signature and automatically sign your commits.

data/{POLICIES.md → doc/rubygems/POLICIES.md}

@@ -65,6 +65,59 @@ Bundler:
     have to work on weekends.
 *   Continue with the regular release process below.
 
+### Branching
+
+Bundler releases are synchronized with rubygems releases at the moment. That
+means that releases for both share the same stable branch, and they should
+generally happen together.
+
+The current conventional naming for stable branches is `x+1.y`, where `x.y` is
+the version of `bundler` that will be released. This is because `rubygems-x+1.y`
+will be released at the same time.
+
+For example, `rubygems-3.2.0` and `bundler-2.2.0` were both released from the
+`3.2` stable branch.
+
+Once a stable branch has been cut from `master`, changes for that minor release
+series are only made _intentionally_, via patch releases. That is to say,
+changes to `master` by default _won't_ make their way into the current stable
+branch, and development on `master` will be targeting the next minor
+or major release.
+
+There is a `bin/rake prepare_release[<target_rubygems_version>]` rake task
+that helps with creating a release. It takes a single argument, the _exact
+rubygems release_ being made (e.g.  `3.2.3` when releasing bundler `2.2.3`).
+This task checks out the appropriate stable branch (`3.2`, for example), grabs
+all merged but unreleased PRs from both bundler & rubygems from GitHub that are
+compatible with the target release level, and then cherry-picks those changes
+(and only those changes) to a new branch based off the stable branch. Then bumps
+the version in all version files, synchronizes both changelogs to include all
+backported changes and commits that change on top of the cherry-picks.
+
+Note that this task requires all user facing pull requests to be tagged with
+specific labels. See [Merging a PR](../bundler/playbooks/MERGING_A_PR.md) for details.
+
+Also note that when this task cherry-picks, it cherry-picks the merge commits
+using the following command:
+
+```bash
+$ git cherry-pick -m 1 MERGE_COMMIT_SHAS
+```
+
+For example, for PR [#5029](https://github.com/rubygems/bundler/pull/5029), we
+cherry picked commit [dd6aef9](https://github.com/rubygems/bundler/commit/dd6aef97a5f2e7173f406267256a8c319d6134ab),
+not [4fe9291](https://github.com/rubygems/bundler/commit/4fe92919f51e3463f0aad6fa833ab68044311f03)
+using:
+
+```bash
+$ git cherry-pick -m 1 dd6aef9
+```
+
+After running the task, you'll have a release branch ready to be merged into the
+stable branch. You'll want to open a PR from this branch into the stable branch
+and provided CI is green, you can go ahead, merge the PR and run release tasks
+as specified below from the updated stable branch.
+
 ### Automatic changelog and backport generation
 
 PR labels and titles are used to automatically generate changelogs for patch and
@@ -79,41 +132,57 @@ changelog.
 If PRs don't have a proper label, they won't be backported to patch releases.
 
 If you want a PR to be backported to a patch level release, but don't want to
-include it in the changelog, you can use the special `rubygems: backport` and
-`bundler: backport` labels. For example, this is useful when backporting a PR
-generates conflicts that are solved by backporting another PR with no user
-visible changes. You can use these special labels to also backport the other PR
-and not get any conflicts.
+include it in the changelog, you can use the special `rubygems: skip changelog`
+and `bundler: skip changelog` labels. For example, this is useful when
+backporting a PR generates conflicts that are solved by backporting another PR
+with no user visible changes. You can use these special labels to also backport
+the other PR and not get any conflicts.
+
+### Breaking changes
+
+Bundler cares a lot about preserving compatibility. As a result, changes that
+break backwards compatibility should (whenever this is possible) include a feature
+release that is backwards compatible, and issue warnings for all options and
+behaviors that will change.
+
+We only release major breaking changes when incrementing the _major_ version of
+Bundler and RubyGems. However, experience shows that almost every single part of
+Bundler and RubyGems is depended on by someone in ways hard to anticipate. So if
+we were strict about breaking changes we'd need to hold on from making progress
+a lot, or continuously increment the major version, emptying "really major"
+versions from their meaning. Because of this, we also may release "small"
+breaking changes in minor releases. "Small" here means that we expect them to
+affect only very few users in rare cases.
 
 ### Steps for patch releases
 
 *   Confirm all PRs that you want backported are properly tagged with `rubygems:
     <type>` or `bundler: <type>` labels at GitHub.
-*   Run `rake prepare_release[<target_version>]`. This will create a PR to the
-    stable branch with the backports included in the release, and proper
-    changelogs and version bumps. It will also create a PR to merge release
-    changelogs into master.
+*   Run `bin/rake prepare_release[<target_rubygems_version>]`. This will create
+    a PR to the stable branch with the backports included in the release, and
+    proper changelogs and version bumps. It will also create a PR to merge
+    release changelogs into master.
 *   Once CI passes, merge the release PR, switch to the stable branch and pull
     the PR just merged.
-*   Release `bundler` with `rake bundler:release`.
-*   Release `rubygems` with `rake release`.
+*   Release `bundler` with `bin/rake bundler:release`.
+*   Release `rubygems` with `bin/rake release`.
 
 ### Steps for minor and major releases
 
 *   Confirm all PRs that you want listed in changelogs are properly tagged with
     `rubygems: <type>` or `bundler: <type>` labels at GitHub.
-*   Run `rake prepare_release[<target_version>]`. This will create a new stable
-    branch off the master branch, and create a PR to it with the proper version
-    bumps and changelogs. It will also create a PR to merge release changelogs
-    into master.
+*   Run `bin/rake prepare_release[<target_rubygems_version>]`. This will create
+    a new stable branch off the master branch, and create a PR to it with the
+    proper version bumps and changelogs. It will also create a PR to merge
+    release changelogs into master.
 *   Replace the stable branch in the workflows with the new stable branch, and
     push that change to the release PR.
 *   Replace version numbers with the next ".dev" version, and push that change
     to the master PR.
 *   Once CI passes, merge the release PR, switch to  the stable branch and pull
     the PR just merged.
-*   Release `bundler` with `rake bundler:release`.
-*   Release `rubygems` with `rake release`.
+*   Release `bundler` with `bin/rake bundler:release`.
+*   Release `rubygems` with `bin/rake release`.
 
 ## Committer Access
 

data/exe/update_rubygems

@@ -34,5 +34,5 @@ else
   update_dir = File.dirname(update_dir)
   Dir.chdir update_dir
   ENV["GEM_PREV_VER"] = Gem::VERSION
-  abort unless system(Gem.ruby, "setup.rb", *ARGV)
+  abort unless system(Gem.ruby, "--disable-gems", "setup.rb", *ARGV)
 end

data/lib/rubygems/basic_specification.rb

@@ -71,11 +71,7 @@ class Gem::BasicSpecification
   # Return true if this spec can require +file+.
 
   def contains_requirable_file?(file)
-    if @ignored
-      return false
-    elsif missing_extensions?
-      @ignored = true
-
+    if ignored?
       if platform == Gem::Platform::RUBY || Gem::Platform.local === platform
         warn "Ignoring #{full_name} because its extensions are not built. " \
              "Try: gem pristine #{name} --version #{version}"
@@ -93,11 +89,34 @@ class Gem::BasicSpecification
     end
   end
 
+  ##
+  # Return true if this spec should be ignored because it's missing extensions.
+
+  def ignored?
+    return @ignored unless @ignored.nil?
+
+    @ignored = missing_extensions?
+  end
+
   def default_gem?
-    loaded_from &&
+    !loaded_from.nil? &&
       File.dirname(loaded_from) == Gem.default_specifications_dir
   end
 
+  ##
+  # Regular gems take precedence over default gems
+
+  def default_gem_priority
+    default_gem? ? 1 : -1
+  end
+
+  ##
+  # Gems higher up in +gem_path+ take precedence
+
+  def base_dir_priority(gem_path)
+    gem_path.index(base_dir) || gem_path.size
+  end
+
   ##
   # Returns full path to the directory where gem's extensions are installed.
 
@@ -115,7 +134,6 @@ class Gem::BasicSpecification
   end
 
   def find_full_gem_path # :nodoc:
-    # TODO: also, shouldn't it default to full_name if it hasn't been written?
     File.expand_path File.join(gems_dir, full_name)
   end
 
@@ -123,10 +141,10 @@ class Gem::BasicSpecification
 
   ##
   # The full path to the gem (install path + full name).
+  #
+  # TODO: This is duplicated with #gem_dir. Eventually either of them should be deprecated.
 
   def full_gem_path
-    # TODO: This is a heavily used method by gems, so we'll need
-    # to aleast just alias it to #gem_dir rather than remove it.
     @full_gem_path ||= find_full_gem_path
   end
 
@@ -143,6 +161,19 @@ class Gem::BasicSpecification
     end
   end
 
+  ##
+  # Returns the full name of this Gem (see `Gem::BasicSpecification#full_name`).
+  # Information about where the gem is installed is also included if not
+  # installed in the default GEM_HOME.
+
+  def full_name_with_location
+    if base_dir != Gem.dir
+      "#{full_name} in #{base_dir}"
+    else
+      full_name
+    end
+  end
+
   ##
   # Full paths in the gem to add to <code>$LOAD_PATH</code> when this gem is
   # activated.
@@ -189,9 +220,11 @@ class Gem::BasicSpecification
   ##
   # Returns the full path to this spec's gem directory.
   # eg: /usr/local/lib/ruby/1.8/gems/mygem-1.0
+  #
+  # TODO: This is duplicated with #full_gem_path. Eventually either of them should be deprecated.
 
   def gem_dir
-    @gem_dir ||= File.expand_path File.join(gems_dir, full_name)
+    @gem_dir ||= find_full_gem_path
   end
 
   ##
@@ -223,6 +256,13 @@ class Gem::BasicSpecification
     raise NotImplementedError
   end
 
+  def installable_on_platform?(target_platform) # :nodoc:
+    return true if [Gem::Platform::RUBY, nil, target_platform].include?(platform)
+    return true if Gem::Platform.new(platform) === target_platform
+
+    false
+  end
+
   def raw_require_paths # :nodoc:
     raise NotImplementedError
   end

data/lib/rubygems/bundler_version_finder.rb

@@ -21,7 +21,7 @@ module Gem::BundlerVersionFinder
   end
 
   def self.bundle_update_bundler_version
-    return unless File.basename($0) == "bundle"
+    return unless ["bundle", "bundler"].include? File.basename($0)
     return unless "update".start_with?(ARGV.first || " ")
     bundler_version = nil
     update_index = nil

data/lib/rubygems/command.rb

@@ -6,7 +6,7 @@
 # See LICENSE.txt for permissions.
 #++
 
-require_relative "optparse"
+require_relative "vendored_optparse"
 require_relative "requirement"
 require_relative "user_interaction"
 
@@ -650,9 +650,6 @@ RubyGems is a package manager for Ruby.
     gem help platforms           gem platforms guide
     gem help <COMMAND>           show help on COMMAND
                                    (e.g. 'gem help install')
-    gem server                   present a web page at
-                                 http://localhost:8808/
-                                 with info about installed gems
   Further information:
     https://guides.rubygems.org
   HELP

data/lib/rubygems/command_manager.rb

@@ -60,6 +60,7 @@ class Gem::CommandManager
     :push,
     :query,
     :rdoc,
+    :rebuild,
     :search,
     :server,
     :signin,
@@ -106,7 +107,7 @@ class Gem::CommandManager
   # Register all the subcommands supported by the gem command.
 
   def initialize
-    require_relative "timeout"
+    require_relative "vendored_timeout"
     @commands = {}
 
     BUILTIN_COMMANDS.each do |name|
@@ -229,18 +230,16 @@ class Gem::CommandManager
   def load_and_instantiate(command_name)
     command_name = command_name.to_s
     const_name = command_name.capitalize.gsub(/_(.)/) { $1.upcase } << "Command"
-    load_error = nil
 
     begin
       begin
         require "rubygems/commands/#{command_name}_command"
-      rescue LoadError => e
-        load_error = e
+      rescue LoadError
+        # it may have been defined from a rubygems_plugin.rb file
       end
+
       Gem::Commands.const_get(const_name).new
     rescue StandardError => e
-      e = load_error if load_error
-
       alert_error clean_text("Loading command: #{command_name} (#{e.class})\n\t#{e}")
       ui.backtrace e
     end

data/lib/rubygems/commands/build_command.rb

@@ -1,11 +1,13 @@
 # frozen_string_literal: true
 
 require_relative "../command"
+require_relative "../gemspec_helpers"
 require_relative "../package"
 require_relative "../version_option"
 
 class Gem::Commands::BuildCommand < Gem::Command
   include Gem::VersionOption
+  include Gem::GemspecHelpers
 
   def initialize
     super "build", "Build a gem from a gemspec"
@@ -75,17 +77,6 @@ Gems can be saved to a specified filename with the output option:
 
   private
 
-  def find_gemspec(glob = "*.gemspec")
-    gemspecs = Dir.glob(glob).sort
-
-    if gemspecs.size > 1
-      alert_error "Multiple gemspecs found: #{gemspecs}, please specify one"
-      terminate_interaction(1)
-    end
-
-    gemspecs.first
-  end
-
   def build_gem
     gemspec = resolve_gem_name
 

data/lib/rubygems/commands/cleanup_command.rb

@@ -38,8 +38,6 @@ class Gem::Commands::CleanupCommand < Gem::Command
     @default_gems    = []
     @full            = nil
     @gems_to_cleanup = nil
-    @original_home   = nil
-    @original_path   = nil
     @primary_gems    = nil
   end
 
@@ -95,9 +93,6 @@ If no gems are named all gems in GEM_HOME are cleaned.
   end
 
   def clean_gems
-    @original_home = Gem.dir
-    @original_path = Gem.path
-
     get_primary_gems
     get_candidate_gems
     get_gems_to_cleanup
@@ -112,17 +107,15 @@ If no gems are named all gems in GEM_HOME are cleaned.
     deps.reverse_each do |spec|
       uninstall_dep spec
     end
-
-    Gem::Specification.reset
   end
 
   def get_candidate_gems
     @candidate_gems = if options[:args].empty?
       Gem::Specification.to_a
     else
-      options[:args].map do |gem_name|
+      options[:args].flat_map do |gem_name|
         Gem::Specification.find_all_by_name gem_name
-      end.flatten
+      end
     end
   end
 
@@ -133,7 +126,7 @@ If no gems are named all gems in GEM_HOME are cleaned.
 
     default_gems, gems_to_cleanup = gems_to_cleanup.partition(&:default_gem?)
 
-    uninstall_from = options[:user_install] ? Gem.user_dir : @original_home
+    uninstall_from = options[:user_install] ? Gem.user_dir : Gem.dir
 
     gems_to_cleanup = gems_to_cleanup.select do |spec|
       spec.base_dir == uninstall_from
@@ -181,8 +174,5 @@ If no gems are named all gems in GEM_HOME are cleaned.
       say "Unable to uninstall #{spec.full_name}:"
       say "\t#{e.class}: #{e.message}"
     end
-  ensure
-    # Restore path Gem::Uninstaller may have changed
-    Gem.use_paths @original_home, *@original_path
   end
 end

data/lib/rubygems/commands/contents_command.rb

@@ -102,15 +102,22 @@ prefix or only the files that are requireable.
   end
 
   def files_in_default_gem(spec)
-    spec.files.map do |file|
-      case file
-      when %r{\A#{spec.bindir}/}
-        # $' is POSTMATCH
-        [RbConfig::CONFIG["bindir"], $']
-      when /\.so\z/
-        [RbConfig::CONFIG["archdir"], file]
+    spec.files.filter_map do |file|
+      if file.start_with?("#{spec.bindir}/")
+        [RbConfig::CONFIG["bindir"], file.delete_prefix("#{spec.bindir}/")]
       else
-        [RbConfig::CONFIG["rubylibdir"], file]
+        gem spec.name, spec.version
+
+        require_path = spec.require_paths.find do |path|
+          file.start_with?("#{path}/")
+        end
+
+        requirable_part = file.delete_prefix("#{require_path}/")
+
+        resolve = $LOAD_PATH.resolve_feature_path(requirable_part)&.last
+        next unless resolve
+
+        [resolve.delete_suffix(requirable_part), requirable_part]
       end
     end
   end
@@ -182,8 +189,8 @@ prefix or only the files that are requireable.
   end
 
   def specification_directories # :nodoc:
-    options[:specdirs].map do |i|
+    options[:specdirs].flat_map do |i|
       [i, File.join(i, "specifications")]
-    end.flatten
+    end
   end
 end