If `bundler _<version>_` is given, I guess the most reasonable approach
is to completely skip version switching, because the user is technically
opting out of it. But since binstubs completely remove this argument
from `ARGV` after processing it, we have no way of detecting that it was
actually passed in the first place in order to skip the feature. So we
set `BUNDLER_VERSION` explicitly in this case.
https://github.com/rubygems/rubygems/commit/e0f360d6d7
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
This reverts commit af604436d8141c34cb2e1e645b9b0d47bfd55a55.
The issue that led to introducing it was never reproduced. I tried to
repro with this patch and it still works just fine. Since this removal
is getting in the middle for some race conditions I'm facing, I'm
reverting the patch.
https://github.com/rubygems/rubygems/commit/2dd267f0e4
This is not detected by the `Performance/StringReplacement` cop, I guess
because of using constants. But still seems like a good change.
Co-authored-by: MSP-Greg <MSP-Greg@users.noreply.github.com>
https://github.com/rubygems/rubygems/commit/f862103133
When installing in parallel, bundler creates several `Gem::Installer`
instances that run in parallel. These installers access the `@@all` class
variable of `Gem::Specification` concurrently.
If a concurrent thread calls `Gem::Specification.reset` (resetting
`@all` to `nil`) while another thread is running
`Gem::Specification._all` or another method that expects `@@all` to be
loaded and not `nil`, that can result in `Enumerable` methods being
called on `nil`, resulting in crashes.
I fix it by protecting the other concurrent access to the `@all`
variable.
https://github.com/rubygems/rubygems/commit/58b343c530
Hiroshi SHIBATA
David Rodríguez
Takuya Noguchi
Nobuyoshi Nakada
Olle Jonsson
bronzdoc