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
This is based on the list in Gem::UpdateSuggestion and Bundler::Fetcher;
these have similar purposes (determining whether/what CI we're executing
in), and can benefit from being combined and updated (they're both
slightly out of date).
Noteable changes:
* We'll consider ourselves to be on a CI in more cases - if CI_NAME or
TASKCLUSTER_ROOT_URL are set specifically, since those represent two
cases that were either overlooked or are no longer covered by the
existing implementation. (Or possibly TaskCluster still does provide
RUN_ID, but failed to document it)
* We will notice/track a few additional services in ci_strings (cirrus,
dsari, taskcluster), stop tracking 'snap' (they went under in 2017),
and update buildbox to buildkite (they've been called that for 8
years, and the BUILDBOX envs have been deprecated for 3).
* We'll also sort/uniq/downcase the values (all of which only matter
because of the special case of CI_NAME).
https://github.com/rubygems/rubygems/commit/60652b942f
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
... to prevent "circular require" when `--disable-gems` is used.
This is a simplified case of e5a0abc5de
```
$ bundle exec ruby -we 'system("ruby", "-w", "--disable-gems", "-e", "")'
<internal:/home/mame/work/ruby/local/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:85: warning: <internal:/home/mame/work/ruby/local/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:85: warning: loading in progress, circular require considered harmful - /home/mame/work/ruby/local/lib/ruby/3.2.0+3/bundler/setup.rb
```
When bundler/setup is require'ed under --disable-gems mode, it loads
rubygems by `require "rubygems" unless defined?(Gem)` in
0b1f682a6d/bundler/lib/bundler/rubygems_integration.rb (L3)
In this case, require'ing bundler/setup from rubygems.rb is circular.
This change makes rubygems.rb to require "bundler/setup" only when
`Bundler` is not defined.
https://github.com/rubygems/rubygems/commit/b4608dee5e
Ruby interpreter loads some special gems at startup: did_you_mean,
error_highlight, and syntax_suggest. These gems are loaded before
`bundler/setup` is loaded by `RUBYOPT=-rbundler/setup`.
So, the versions of the gems are not controllable by Gemfile.
This change will `require "bundler/setup"` in rubygems.rb (i.e., before
the special gems are loaded). Now `bundle exec` sets an environment
variable `BUNDLER_SETUP`, and rubygems requires the variable if defined.
See also: https://bugs.ruby-lang.org/issues/19089https://github.com/rubygems/rubygems/commit/963cb65a2d
It was being explicitly required from `Gem::Specification` but also a
strange autoload was set for it at `Gem::Version`. The autoload was non
standard because it should've been done in the `Gem` module, not in
`Gem::Specification`, since that's where the constant is expected to get
defined. Doing this might get deprecated in the future, and it was not
being effective anyways due to the explicit require.
Unify everything with an `autoload` at the right place.
https://github.com/rubygems/rubygems/commit/174ea3e24c