If a gem is required circular, and there are unresolved specs depending
on it, we may end up in an activation conflict.
The solution is to not try to activate unresolved gems when requiring a
default gem, regardless of it having already been activated or not.
https://github.com/rubygems/rubygems/commit/3b2b8f4e3e
The following conditions must be met:
* A default gem is required.
* A previous require left some gems unresolved, and those dependencies
themselves depend on the default gem.
In this case, rubygems require will first activate the default version
of the gem, then try to activate another unresolved version of the
default gem that conflicts with the first activation.
The solution is, if we are in the middle of requiring a default gem,
skip this step, because we have already activated it successfully.
https://github.com/rubygems/rubygems/commit/8cd5608db5
Co-authored-by: Stan Hu <stanhu@gmail.com>
I've seen this error sometimes but never found it helpful, since the
culprit has never been thread/monitor related, so it just adds noise.
Right now I'm seeing an issue in CI where we seem to be crashing during
ensure and showing a weird backtrace:
```
#<Thread:0x000055821d7a73b8 /home/runner/work/rubygems/rubygems/lib/rubygems/request_set.rb:167 run> terminated with exception (report_on_exception is true):
/home/runner/work/rubygems/rubygems/lib/rubygems/platform.rb:141:in `==': undefined local variable or method `to_a' for false:FalseClass (NameError)
Did you mean? to_s
from /home/runner/work/rubygems/rubygems/lib/rubygems/core_ext/kernel_require.rb:168:in `!='
from /home/runner/work/rubygems/rubygems/lib/rubygems/core_ext/kernel_require.rb:168:in `require'
from /home/runner/work/rubygems/rubygems/lib/rubygems.rb:441:in `block in ensure_subdirectories'
from /home/runner/work/rubygems/rubygems/lib/rubygems.rb:437:in `each'
from /home/runner/work/rubygems/rubygems/lib/rubygems.rb:437:in `ensure_subdirectories'
from /home/runner/work/rubygems/rubygems/lib/rubygems.rb:413:in `ensure_gem_subdirectories'
from /home/runner/work/rubygems/rubygems/lib/rubygems/resolver/specification.rb:110:in `download'
from /home/runner/work/rubygems/rubygems/lib/rubygems/request_set.rb:173:in `block (2 levels) in install'
```
Let's get this out of the picture in case that helps clarify the
culprit.
https://github.com/rubygems/rubygems/commit/87ce40b70e
Currently Bundler needs to do cumbersome operations to revert custom
RubyGems require on a `bundler/setup` context. This causes issues when
third party gems also monkeypatch require, since Bundler will also undo
those decorations.
This commit allows it to use the simpler approach of properly telling
RubyGems that it needs to default to built-in require without any extra
magic.
https://github.com/rubygems/rubygems/commit/1df5009e14
Co-authored-by: Xavier Noria <fxn@hashref.com>
Since RDoc does not parse string literals as documents, `eval` the
entire file instead of embedding in a here-document.
On the contrary, as `gem_original_require` alias is an implementation
detail but not for users, it should not be documented.
https://github.com/rubygems/rubygems/commit/cad4cf16cf
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
This reverts commit d9978ce5d397866afae536db2aa708af3b7a4b2f.
Untaint was tentatively restored due to test failures. But now, the
failed tests have been removed, so we can revert the tentative fix.
`File.symlink? safe_lp` can raise SecurityError and raising an
exception can leave RUBYGEMS_ACTIVATION_MONITOR locking. This
patch release it correctly.
* Fix gem pristine not accounting for user installed gems. Pull request
#2914 by Luis Sagastume.
* Refactor keyword argument test for Ruby 2.7. Pull request #2947 by
SHIBATA Hiroshi.
* Fix errors at frozen Gem::Version. Pull request #2949 by Nobuyoshi
Nakada.
* Remove taint usage on Ruby 2.7+. Pull request #2951 by Jeremy Evans.
* Check Manifest.txt is up to date. Pull request #2953 by David Rodríguez.
* Clarify symlink conditionals in tests. Pull request #2962 by David
Rodríguez.
* Update command line parsing to work under ps. Pull request #2966 by
David Rodríguez.
* Properly test `Gem::Specifications.stub_for`. Pull request #2970 by
David Rodríguez.
* Fix Gem::LOADED_SPECS_MUTEX handling for recursive locking. Pull request
#2985 by MSP-Greg.
I noticed that some files in rubygems were executable, and I could think
of no reason why they should be.
In general, I think ruby files should never have the executable bit set
unless they include a shebang, so I run the following command over the
whole repo:
```bash
find . -name '*.rb' -type f -executable -exec bash -c 'grep -L "^#!" $1 || chmod -x $1' _ {} \;
```
