| Age | Commit message (Collapse) | Author |
|---|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/3213
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/3213
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/3213
|
|
Namely, those generated under `/tmp`.
The previous approach was brittle and broken in the case of ruby-core,
because under that setup, the current folder is in the original
`$LOAD_PATH`, and dummy features are created under `./tmp`, so they were
failing to be reset.
Notes:
Merged: https://github.com/ruby/ruby/pull/3213
|
|
This was guaranteed by our gitignore setup where a `tmp/` folder is
always present right after cloning the repository, but was not
guaranteed under the ruby-core setup.
This alternative approach should always work.
Notes:
Merged: https://github.com/ruby/ruby/pull/3213
|
|
This reverts commit 20971d0df41368e0f946683823bc786514e16fef.
Notes:
Merged: https://github.com/ruby/ruby/pull/3213
|
|
This was added ~8 years to fix some json warning but I'm pretty sure
it's not needed anymore.
This has caused several issues in both ruby-core and rdoc test suite and
it doesn't make much sense to me these days so let's kill it.
Notes:
Merged: https://github.com/ruby/ruby/pull/3213
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/3229
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/3229
|
|
They are no longer needed since ruby 2.0.
Notes:
Merged: https://github.com/ruby/ruby/pull/3229
|
|
There's better tools for this job.
Notes:
Merged: https://github.com/ruby/ruby/pull/3229
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/3229
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/3229
|
|
To make rubygems code style consistent with bundler.
Notes:
Merged: https://github.com/ruby/ruby/pull/3229
|
|
In `ruby-head` (where system rubygems already has the `XDG` standard
implementation), some tests currently depend on the presence of a
`~/.gem` folder in the home of the user that runs the tests. If that
file is present, tests pass, otherwise they don't.
For example, the following passes if you have a `~/.gem` folder but
fails otherwise with:
```
$ rake TESTOPTS="--name=/TestGemCommandsGenerateIndexCommand#test_execute$\|TestGemCommandsUpdateCommand#test_execute_user_install/ -v"
Run options: "--name=/TestGemCommandsGenerateIndexCommand#test_execute$|TestGemCommandsUpdateCommand#test_execute_user_install/" -v --seed 17318
# Running:
TestGemCommandsGenerateIndexCommand#test_execute = 0.02 s = .
TestGemCommandsUpdateCommand#test_execute_user_install = /rubygems/test/rubygems/test_gem_commands_update_command.rb:412: warning: instance variable @user_install not initialized
0.04 s = F
Finished in 0.095337s, 20.9783 runs/s, 20.9783 assertions/s.
1) Failure:
TestGemCommandsUpdateCommand#test_execute_user_install [/rubygems/test/rubygems/test_gem_commands_update_command.rb:414]:
user_install must be set on the installer
2 runs, 2 assertions, 1 failures, 0 errors, 0 skips
rake aborted!
Command failed with status (1)
Tasks: TOP => default => test
(See full trace by running task with --trace)
```
This is because the very initial `require` of the default `did_you_mean`
gem that ruby does on startup runs _before_ the global `setup` hook of
our tests run. During this require `Gem.data_home` and its value is
memoized to a path in the real users home (not the fake user's home that
our tests setup, since that code hasn't run yet). Then that memoized
value is used when looking for the default folders to look for gems, and
since there's no `~/.gem` folder, its value is actually used as part of
the `Gem.user_dir` folder in `Gem::Specification.dirs` (this is how
we've approached backwards compatibility for the `XDG` feature). That
means dummy test gems with the `--user-install` flag are installed to
global, real locations and everything is messed up.
This commit fixes the issue by resetting the `Gem.data_home` value in
case it has already been memoized.
Notes:
Merged: https://github.com/ruby/ruby/pull/3211
|
|
This reverts commit ac2c07e98373bb62be618001c897fa9d5809d8a4.
Notes:
Merged: https://github.com/ruby/ruby/pull/3211
|
|
'require'
https://github.com/rubygems/rubygems/commit/5995394ec4
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
https://github.com/rubygems/rubygems/commit/f4fe949dfa
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
https://github.com/rubygems/rubygems/commit/55b09a7aa2
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
https://github.com/rubygems/rubygems/commit/32c7f7f484
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
It's not so basic anymore, and it does much more than validating
required fields.
https://github.com/rubygems/rubygems/commit/3c0be4cdeb
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
https://github.com/rubygems/rubygems/commit/3a44b6f846
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
https://github.com/rubygems/rubygems/commit/c87ac90528
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
https://github.com/rubygems/rubygems/commit/b4948bda74
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
- this would keep the could-be-a-string-method matches few
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
https://github.com/rubygems/rubygems/commit/f3da3c1190
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
The code is quite different now, so I think the link might be even
confusing. If you want to know more, use git history.
https://github.com/rubygems/rubygems/commit/db872c7a18
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
In the cases where the initial manually `-I` path resolution succeeded,
we were passing a full path to the original require effectively skipping
the `$LOADED_FEATURES` cache. With this change, we _only_ do the
resolution when a matching requirable path is found in a default gem. In
that case, we skip activation of the default gem if we detect that the
required file will be picked up for a `-I` path.
https://github.com/rubygems/rubygems/commit/22ad5717c3
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
https://github.com/rubygems/rubygems/commit/da1492e9d7
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
https://github.com/rubygems/rubygems/commit/ae95885dff
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
Our check for `-I` paths should not go through all activated gems.
https://github.com/rubygems/rubygems/commit/00d98eb8a3
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
Currently we get the following warnings on `ruby setup.rb`:
```
/home/deivid/.rbenv/versions/2.7.1/lib/ruby/site_ruby/2.7.0/rubygems/exceptions.rb:281: warning: already initialized constant Gem::UnsatisfiableDepedencyError
/home/deivid/Code/rubygems/lib/rubygems/exceptions.rb:281: warning: previous definition of UnsatisfiableDepedencyError was here
/home/deivid/.rbenv/versions/2.7.1/lib/ruby/site_ruby/2.7.0/rubygems/user_interaction.rb:557: warning: already initialized constant Gem::StreamUI::ThreadedDownloadReporter::MUTEX
/home/deivid/Code/rubygems/lib/rubygems/user_interaction.rb:557: warning: previous definition of MUTEX was here
/home/deivid/.rbenv/versions/2.7.1/lib/ruby/site_ruby/2.7.0/rubygems/ext/builder.rb:20: warning: already initialized constant Gem::Ext::Builder::CHDIR_MUTEX
/home/deivid/Code/rubygems/lib/rubygems/ext/builder.rb:20: warning: previous definition of CHDIR_MUTEX was here
/home/deivid/.rbenv/versions/2.7.1/lib/ruby/site_ruby/2.7.0/rubygems/ext/ext_conf_builder.rb:14: warning: already initialized constant Gem::Ext::ExtConfBuilder::FileEntry
/home/deivid/Code/rubygems/lib/rubygems/ext/ext_conf_builder.rb:14: warning: previous definition of FileEntry was here
/home/deivid/.rbenv/versions/2.7.1/lib/ruby/site_ruby/2.7.0/rubygems/version.rb:158: warning: already initialized constant Gem::Version::VERSION_PATTERN
/home/deivid/Code/rubygems/lib/rubygems/version.rb:158: warning: previous definition of VERSION_PATTERN was here
/home/deivid/.rbenv/versions/2.7.1/lib/ruby/site_ruby/2.7.0/rubygems/version.rb:159: warning: already initialized constant Gem::Version::ANCHORED_VERSION_PATTERN
/home/deivid/Code/rubygems/lib/rubygems/version.rb:159: warning: previous definition of ANCHORED_VERSION_PATTERN was here
/home/deivid/.rbenv/versions/2.7.1/lib/ruby/site_ruby/2.7.0/rubygems/requirement.rb:14: warning: already initialized constant Gem::Requirement::OPS
/home/deivid/Code/rubygems/lib/rubygems/requirement.rb:14: warning: previous definition of OPS was here
/home/deivid/.rbenv/versions/2.7.1/lib/ruby/site_ruby/2.7.0/rubygems/requirement.rb:24: warning: already initialized constant Gem::Requirement::SOURCE_SET_REQUIREMENT
/home/deivid/Code/rubygems/lib/rubygems/requirement.rb:24: warning: previous definition of SOURCE_SET_REQUIREMENT was here
/home/deivid/.rbenv/versions/2.7.1/lib/ruby/site_ruby/2.7.0/rubygems/requirement.rb:27: warning: already initialized constant Gem::Requirement::PATTERN_RAW
/home/deivid/Code/rubygems/lib/rubygems/requirement.rb:27: warning: previous definition of PATTERN_RAW was here
/home/deivid/.rbenv/versions/2.7.1/lib/ruby/site_ruby/2.7.0/rubygems/requirement.rb:32: warning: already initialized constant Gem::Requirement::PATTERN
/home/deivid/Code/rubygems/lib/rubygems/requirement.rb:32: warning: previous definition of PATTERN was here
/home/deivid/.rbenv/versions/2.7.1/lib/ruby/site_ruby/2.7.0/rubygems/requirement.rb:37: warning: already initialized constant Gem::Requirement::DefaultRequirement
/home/deivid/Code/rubygems/lib/rubygems/requirement.rb:37: warning: previous definition of DefaultRequirement was here
/home/deivid/.rbenv/versions/2.7.1/lib/ruby/site_ruby/2.7.0/rubygems/requirement.rb:42: warning: already initialized constant Gem::Requirement::DefaultPrereleaseRequirement
/home/deivid/Code/rubygems/lib/rubygems/requirement.rb:42: warning: previous definition of DefaultPrereleaseRequirement was here
/home/deivid/.rbenv/versions/2.7.1/lib/ruby/site_ruby/2.7.0/rubygems/requirement.rb:311: warning: already initialized constant Gem::Version::Requirement
/home/deivid/Code/rubygems/lib/rubygems/requirement.rb:311: warning: previous definition of Requirement was here
/home/deivid/.rbenv/versions/2.7.1/lib/ruby/site_ruby/2.7.0/rubygems/command.rb:626: warning: already initialized constant Gem::Command::HELP
/home/deivid/Code/rubygems/lib/rubygems/command.rb:626: warning: previous definition of HELP was here
Successfully built RubyGem
Name: bundler
Version: 2.2.0.dev
File: bundler-2.2.0.dev.gem
Bundler 2.2.0.dev installed
RubyGems 3.2.0.pre1 installed
Regenerating binstubs
Regenerating plugins
------------------------------------------------------------------------------
RubyGems installed the following executables:
/home/deivid/.rbenv/versions/2.7.1/bin/gem
/home/deivid/.rbenv/versions/2.7.1/bin/bundle
```
This is because the `$LOAD_PATH` entry added by `setup.rb` is relatively
and when the offending require happens, we're installing `bundler` and
have switched folders to `bundler/`. So the require fallsback to the
system rubygems.
To avoid that, add an absolute path to the `$LOAD_PATH`.
On jruby, somehow the $LOAD_PATH is manipulated so that we end up
requiring stuff inside the built package even if we have specified the
`-I` flag, so we get redefinition warnings anyways.
I'm not sure about the root cause, but relative requiring fixes it, and
it's faster anyways.
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
in warning.
https://github.com/rubygems/rubygems/commit/5e31e1a421
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
but rake is not specified as dependency.
https://github.com/rubygems/rubygems/commit/75fe5475b6
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
- In one of the cases, filenames were checked for ending with "gz" -
this is changed to check for ending with ".gz"
- The change was made to make it even easier to read the code, and to
match only from the start of the input (as opposed to start of the
line)
https://github.com/rubygems/rubygems/commit/aac4290271
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
https://github.com/rubygems/rubygems/commit/10cc79ee21
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
https://github.com/rubygems/rubygems/commit/a82a77251d
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
https://github.com/rubygems/rubygems/commit/97772bb066
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
https://github.com/rubygems/rubygems/commit/73c199b087
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
If the following conditions are met:
* You have a default version of fileutils and a higher version of
fileutils installed as a regular gem. This case is common on ruby 2.6.
* You use a bundler generated binstub on a gem setup with a `Gemfile`
using the `gemspec` DSL.
Then `fileutils` redefinition warnings happen because of the following:
The gist of a bundler generated binstub is:
```ruby
require "bundler/setup"
load Gem.bin_path("rake", "rake")
```
First configure bundler, then load the requested gem.
When `require "bundler/setup"` is called under the previously mentioned
setup, `ext_conf_builder.rb` ends up being required because of the new
validation that gemspecs with rake extensions depend on `rake`. And that
loads the latest version of `fileutils` because of using "rubygems
monkeypatched require" that auto-chooses the latest version of default
gems.
After that, when `Gem.bin_path` gets called, `ext_conf_builder.rb` gets
required again, but this time already using "bundler's unmonkeypatched
require" which means the default version is chosen and thus the
redefinition warning happens.
The solution as usual is to lazily load `fileutils`.
https://github.com/rubygems/rubygems/commit/08d64e5f06
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
The logging to $stderr is only happening due to a bug in `FileUtils`.
Logging messages are not errors.
https://github.com/rubygems/rubygems/commit/4d1b6659e6
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
This reverts an unintentional change in commit
79d9528ddca1dfe2dd99287dc88fd7c2b30f7137.
|
|
Create a wrapper object first, then buffer allocation which can
fail.
|
|
This reverts commit 93d1588c782ab9d61699f98b6c64d7f0ab8121c0.
Notes:
Merged: https://github.com/ruby/ruby/pull/3092
|
|
This reverts commit e98455f289047c43a733e61ac6317fb74b68de82.
Notes:
Merged: https://github.com/ruby/ruby/pull/3092
|
|
Instead, make each test cleanup after itself.
https://github.com/rubygems/rubygems/commit/e0aba9d64f
Notes:
Merged: https://github.com/ruby/ruby/pull/3092
|
|
https://github.com/rubygems/rubygems/commit/b0c55c76ca
Notes:
Merged: https://github.com/ruby/ruby/pull/3092
|
|
and `Gem::Specification.stubs_for`
The rationale is that:
* The change has caused realworld issues. See for example
https://github.com/ruby/did_you_mean/issues/117 and specifically [this
comment](https://github.com/ruby/did_you_mean/issues/117#issuecomment-482733159)
for a great explanation of the issue it caused for `did_you_mean`.
* The change also causes problems for our development workflows. For
example, because of it, our `bundler` specs cannot currently be run with
`bin/rake` and we have to use `bin/rspec` or `bin/parallel_spec`
directly. The explanation for this is:
- Our specs install test dependencies to `tmp` before running specs.
- `rake` is one of these test dependencies.
- Before installing each test dependency, we check whether it has
matching installed specs: https://github.com/rubygems/rubygems/blob/2bbcdcde08b90d4ef03da8fb1f7a8a3313e13bb8/bundler/spec/support/rubygems_ext.rb#L109-L114.
- Normally, if `rake` has not yet been installed to `tmp`, this check
fails and `rake` is installed, but since the loaded specs are now
added to `Gem::Specification.stubs` and `rake`'s specification _is_
loaded because we're running through `bin/rake`, the check incorrectly
assumes that `rake` is already installed to `tmp` and skips
installation.
- At a later point the specs check whether `rake` is actually
installed and fail if it's not: https://github.com/rubygems/rubygems/blob/2bbcdcde08b90d4ef03da8fb1f7a8a3313e13bb8/bundler/spec/support/builders.rb#L372-L383
Essentially, both of the issues are the same. If at runtime we change
the location of gems, we'll _want_ to not consider loaded specifications
when dealing with the new gem location, because the loaded
specifications have not been loaded from there. Loaded specifications is
something different from installed stub specifications and those should
not be mixed.
The PR still seemed to have fixed an issue, so I did my archaeology job
and investigated the original issue to double check if reverting is ok.
The logs for the original error can be found here:
https://ci.appveyor.com/project/rubygems/rubygems/build/1172/job/ogubyucpljcv22ux.
So I installed ruby 2.4.4, checked out the commit reference before the
offending PR, and the exact error reproduced. :tada:
```
$ rake test
/home/deivid/Code/rubygems/lib/rubygems/resolver.rb:231:in `search_for': Unable to resolve dependency: user requested 'bundler (= 1.16.2)' (Gem::UnsatisfiableDependencyError)
from /home/deivid/Code/rubygems/lib/rubygems/resolver.rb:283:in `block in sort_dependencies'
from /home/deivid/Code/rubygems/lib/rubygems/resolver.rb:277:in `each'
from /home/deivid/Code/rubygems/lib/rubygems/resolver.rb:277:in `sort_by'
from /home/deivid/Code/rubygems/lib/rubygems/resolver.rb:277:in `with_index'
from /home/deivid/Code/rubygems/lib/rubygems/resolver.rb:277:in `sort_dependencies'
from /home/deivid/Code/rubygems/lib/rubygems/resolver/molinillo/lib/molinillo/delegates/specification_provider.rb:52:in `block in sort_dependencies'
from /home/deivid/Code/rubygems/lib/rubygems/resolver/molinillo/lib/molinillo/delegates/specification_provider.rb:69:in `with_no_such_dependency_error_handling'
from /home/deivid/Code/rubygems/lib/rubygems/resolver/molinillo/lib/molinillo/delegates/specification_provider.rb:51:in `sort_dependencies'
from /home/deivid/Code/rubygems/lib/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:165:in `initial_state'
from /home/deivid/Code/rubygems/lib/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:106:in `start_resolution'
from /home/deivid/Code/rubygems/lib/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:64:in `resolve'
from /home/deivid/Code/rubygems/lib/rubygems/resolver/molinillo/lib/molinillo/resolver.rb:42:in `resolve'
from /home/deivid/Code/rubygems/lib/rubygems/resolver.rb:188:in `resolve'
from /home/deivid/Code/rubygems/lib/rubygems/request_set.rb:396:in `resolve'
from /home/deivid/Code/rubygems/lib/rubygems/request_set.rb:408:in `resolve_current'
from /home/deivid/Code/rubygems/lib/rubygems.rb:243:in `finish_resolve'
from /home/deivid/Code/rubygems/lib/rubygems/rdoc.rb:13:in `<top (required)>'
from /home/deivid/Code/rubygems/lib/rubygems/core_ext/kernel_require.rb:54:in `require'
from /home/deivid/Code/rubygems/lib/rubygems/core_ext/kernel_require.rb:54:in `require'
from /home/deivid/Code/rubygems/lib/rubygems/test_case.rb:1563:in `<top (required)>'
from /home/deivid/Code/rubygems/test/rubygems/test_bundled_ca.rb:2:in `require'
from /home/deivid/Code/rubygems/test/rubygems/test_bundled_ca.rb:2:in `<top (required)>'
from /home/deivid/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/rake-12.0.0/lib/rake/rake_test_loader.rb:15:in `require'
from /home/deivid/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/rake-12.0.0/lib/rake/rake_test_loader.rb:15:in `block in <main>'
from /home/deivid/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/rake-12.0.0/lib/rake/rake_test_loader.rb:4:in `select'
from /home/deivid/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/rake-12.0.0/lib/rake/rake_test_loader.rb:4:in `<main>'
rake aborted!
Command failed with status (1)
Tasks: TOP => test
```
Now the explanation of the error:
* Rubygems base `TestCase` class requires `bundler` because some tests
use `bundler`:
https://github.com/rubygems/rubygems/blob/2bbcdcde08b90d4ef03da8fb1f7a8a3313e13bb8/lib/rubygems/test_case.rb#L26
* That `require` (our custom rubygems require) would activate the
default bundler spec (1.16.1 for ruby 2.4.4) but then overwrite it with
a 1.16.2 version (the locally provided bundler those days) due to [this
old
hack](https://github.com/rubygems/bundler/blob/9f7bf0ac3ab8d995e3a274cec3c292a5203f4534/lib/bundler/version.rb#L7-L23).
* Rubygems base `TestCase` class requires `rubygems/rdoc`:
https://github.com/rubygems/rubygems/blob/2bbcdcde08b90d4ef03da8fb1f7a8a3313e13bb8/lib/rubygems/test_case.rb#L1536
* And that file ends up calling `Gem.finish_resolve`:
https://github.com/rubygems/rubygems/blob/2bbcdcde08b90d4ef03da8fb1f7a8a3313e13bb8/lib/rubygems/rdoc.rb#L13
* `Gem.finish_resolve` adds the currently loaded specs to the
resolution:
https://github.com/rubygems/rubygems/blob/2bbcdcde08b90d4ef03da8fb1f7a8a3313e13bb8/lib/rubygems.rb#L235
* That means it would try to resolve bundler 1.16.2, but no
specification for that version was installed since the default was
1.16.1. That explains why upgrading to rubygems 2.7.7 fixed the issue,
since it provided bundler 1.16.2 by default so there was not bundler
version discrepancy.
After understanding the error, I conclude that:
* Only this part of the original patch was actually needed to resolve
the error, not any of the changes in `Gem::Specification.stubs` and
`Gem::Specification.stubs_for`:
```diff
diff --git a/lib/rubygems/test_case.rb b/lib/rubygems/test_case.rb
index f1cd3d274c..92c848e870 100644
--- a/lib/rubygems/test_case.rb
+++ b/lib/rubygems/test_case.rb
@@ -13,6 +13,15 @@ else
require 'rubygems'
end
+# If bundler gemspec exists, add to stubs
+bundler_gemspec = File.expand_path("../../../bundler/bundler.gemspec", __FILE__)
+if File.exist?(bundler_gemspec)
+ Gem::Specification.dirs.unshift File.dirname(bundler_gemspec)
+ Gem::Specification.class_variable_set :@@stubs, nil
+ Gem::Specification.stubs
+ Gem::Specification.dirs.shift
+end
+
begin
gem 'minitest'
rescue Gem::LoadError
```
So, I propose to revert adding loaded specification to
`Gem::Specification.stubs` and `Gem::Specification.stubs_for` because I
think it's safe, it fixes the issues caused by their addition, and it
simplifies `Gem::Specification` code, which is already complicated
enough.
https://github.com/rubygems/rubygems/commit/5269cd617c
Notes:
Merged: https://github.com/ruby/ruby/pull/3092
|
|
Originally, the call to `.stubs_for` allowed to incrementally populate
the `@@stubs_by_name` (especially see the `"#{name}-*.gemspec"` pattern
in 4fa03bb7aac9f25f44394e818433fdda9962ae8d). Now it looks like it
expects that all stubs are loaded, but the `.stubs_for` still matches
the .gemspec files by the `name` pattern:
https://github.com/rubygems/rubygems/blob/6d45e0f7ac1caca22900e39f703e226c4cfdebf7/lib/rubygems/specification.rb#L845
I think this was done by mistake incrementally by PR #1239 and
4cee8ca9199ac7b3ab8647e0b78615f55d3eb02b. I think the best option is to
get back to the original implementation, to let RubyGems incrementally
populate the array. Other option would be to replace the logic in
`.stub_for` by call to `.stubs`, but the means the performance
improvement from the original commit was lost.
https://github.com/rubygems/rubygems/commit/4d0e18185a
Notes:
Merged: https://github.com/ruby/ruby/pull/3092
|
|
This list of exceptions is no longer rescued since
1f03275ff3faa1c808d3a3b89ef5db62dc2eb2ba.
https://github.com/rubygems/rubygems/commit/6e71e7be67
Notes:
Merged: https://github.com/ruby/ruby/pull/3092
|
