... 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
When bundler parallel installer installs gems concurrently, one can get
confusing warnings like the following:
```
"[/home/runner/work/rubygems/rubygems/bundler/tmp/2/gems/system/specifications/zeitwerk-2.4.2.gemspec] isn't a Gem::Specification (NilClass instead).
```
I've got these warnings several times in the past, but I never managed
to reproduce them, and never look deeply into the root cause, but this
time a got a cause that reproduced quite frequently, so I looked into
it.
The problem is one thread reading a gemspec while another thread is
writing it. The write of the gemspec was not protected, so
`Gem::Specification.load` could end up seeing a truncated gemspec and
thus throw this warning.
The fix involve two changes:
* Change the methods that write gemspecs to use `Gem.binary_write` which
is protected by a lock.
* Fix `Gem.binary_write` to create the file lock at file creation time,
not when the file already exists after.
The realworld user problem caused by this issue happens in bundler, but
I'm fixing it in rubygems first, and then I'll backport to bundler
whatever needs backporting to fix the issue on the bundler side.
https://github.com/rubygems/rubygems/commit/a672e7555c
We think it's unlikely that `rubygems/defaults/operating_system` could be shipped with a SyntaxError so StandardError could be better choice to prevent "false positives" errors.
https://github.com/rubygems/rubygems/commit/1f73e784dd
When loading `rubygems/defaults/operating_system`
- we want to keep it silent if the raised exception is a LoadError
- we want to print a message in other cases and ask users to report the issue to their OS support.
Ruby 3 comes with special error handling for loading `rubygems` and it will show a warning when LoadError exception raised for requiring 'rubygem'.
Because of that, we decided to leave the LoadError scenario as it is.
Reference: d1998d8767/gem_prelude.rb (L1-L5)https://github.com/rubygems/rubygems/commit/0a97e12fe1
As far as I understand, this block should only be run when
`bundler/setup` fails. The only other case where these errors could be
run is when bundler itself is required.
If bundler itself fails to be required or activated (like in old rubies
where it was not a default gem, for example), the raw error is much more
helpful than this message.
So we can move the rescue after bundler is succesfully required, and
that simplifies the list of exceptions that we need to track to just
`Bundler::Error`.
https://github.com/rubygems/rubygems/commit/3663c11e93
After reading [this blog
post](https://blog.rubygems.org/2011/08/31/shaving-the-yaml-yak.html),
published almost 10 years ago already, my understanding is that this
problem could come up in two ways:
* Rubygems.org serving corrupted gemspecs". As far as I understand this
was fixed in rubygems.org a lot time ago, since
https://github.com/rubygems/rubygems.org/pull/331.
* Clients having a ten years old gemspec cache with some of these bad
gemspecs. In this case, there's no easy solution but I think ten years
is enough and rebuilding the cache should do the trick.
So, I think it's time we remove this.
https://github.com/rubygems/rubygems/commit/afcb15d556
Ellen Marie Dash
Yusuke Endoh
Hiroshi SHIBATA
Takuya Noguchi
David Rodríguez
Peter Zhu
Kazuhiro NISHIYAMA
Masataka Pocke Kuwabara
Kevin Logan
Daniel Niknam