As far as I could see, `Gem::Resolver::APISpecification` objects are
supposed to be immutable. If my guessing is correct, then we can cache
and reuse its instances for performance.
At least, `rake` passes on my machine.
Before this change:
```
$ time ruby -I lib bin/gem install --no-doc aws-sdk
Successfully installed aws-sdk-3.0.1
1 gem installed
real 0m37.104s
user 0m36.952s
sys 0m0.333s
```
After this change:
```
$ time ruby -I lib bin/gem install --no-doc aws-sdk
Successfully installed aws-sdk-3.0.1
1 gem installed
real 0m23.905s
user 0m23.740s
sys 0m0.365s
```
https://github.com/rubygems/rubygems/commit/7e8fbba85c
This restores 3.0 behavior and goes back to not formatting executables
by default on `gem update --system`. This is friendlier for jruby and
doesn't really affect OS packagers.
https://github.com/rubygems/rubygems/commit/1a504b651d
This reverts commit 694e6afee769ffb3168a564ee7d315af2a934993.
It was failed on Windows and I'm unsure why. Also, the check seems
brittle since it could fail potentially fail because of warnings outside
of our control.
https://github.com/rubygems/rubygems/commit/908e9344dd
If any error happens while verifying a package entry, it doesn't mean
that the package is corrupt. It could be a bug in rubygems, for example.
This in fact happened in CI and the current error doesn't make it easy
to troubleshoot the root cause, since it doesn't provide a backtrace.
See
https://github.com/rubygems/rubygems/pull/3807/checks?check_run_id=862526615.
So I propose to let the exception happens. There was something useful
about the previous message, which is the file entry where the error
happened, so I'm keeping that information in a warning message.
https://github.com/rubygems/rubygems/commit/ece87d858f
The `openssl` require when openssl not present was having the
side-effect the our custom require fallbacks would end up loading `Gem::Specification.stubs`.
Co-authored-by: Alyssa Ross <hi@alyssa.is>
https://github.com/rubygems/rubygems/commit/22c4ded4ad
It's very unlikely to hit this case, but it is possible, as
Thread::Backtrace::Location#path can return nil if the location is
a cfunc with no previous iseq. See location_path in vm_backtrace.c
in Ruby.
https://github.com/rubygems/rubygems/commit/511935645a
* See https://github.com/oracle/truffleruby/issues/2046
* `<internal:` is a common prefix also used by core Ruby files in CRuby.
* test_no_kernel_require_in_*warn_with_uplevel already test this.
* Unfortunately just skipping `<internal:` in the Ruby implementation
is not enough, because RubyGems' #warn would not skip the
`<internal:` require (TruffleRuby defines #require in Ruby),
and the Ruby implementation's #warn would not skip
RubyGems's #require. The #caller_locations(0) look like this:
warnee.rb:1:in `<top (required)>' # where #warn is called
<internal:core> core/kernel.rb:234:in `gem_original_require' # not skipped by RubyGems' warn, skipped by the Ruby impl
rubygems/core_ext/kernel_require.rb:54:in `require' # not skipped by the Ruby impl's warn, what would be shown without this fix
warn.rb:1:in `<main>' # what would be correct
warn.rb is
require "warnee"
warnee.rb is
puts caller_locations(0), nil
warn "oops", uplevel: 1
https://github.com/rubygems/rubygems/commit/7c838f7419
It was added 10 years ago on a "146 additions, 170 deletions" commit
named "Deprecation removals and minor cleanup." that didn't explain much
other than that.
This TODO doesn't necessarily apply nowadays. I don't see how anyways.
TODO notes, if useful at all, should include a clear explanation of what
should be done either via the note itself or the commit message. This
note doens't meet any of these.
So I want to remove it because it distracts me every time I go through
it.
https://github.com/rubygems/rubygems/commit/58d81e8a32
The previous commit introduces the Gem::Security.create_digest method, allowing to:
- decouple algorithm choice from implementation (OpenSSL or Ruby built-in)
- untangle the SHA512 fallback for TarWriter from the generic hashing digest choice (undoing commit 9471f8ed2bdc12248d2619bbbce6e53cd6c16cb6)
https://github.com/rubygems/rubygems/commit/1bc03231e4