Skip to content

[pull] master from ruby:master#862

Merged
pull[bot] merged 9 commits intoturkdevops:masterfrom
ruby:master
Mar 18, 2026
Merged

[pull] master from ruby:master#862
pull[bot] merged 9 commits intoturkdevops:masterfrom
ruby:master

Conversation

@pull
Copy link

@pull pull bot commented Mar 18, 2026

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

colby-swandale and others added 9 commits March 18, 2026 07:58
When install_gem runs Gem::Installer in-process, BUNDLER_SPEC_PLATFORM
is not applied because hax.rb only runs in subprocesses. Add
with_simulated_platform helper that mirrors hax.rb's platform override
for in-process operations, and restore psych in standalone extension
test's base_system_gems.

ruby/rubygems@b9c831ab54

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
With load_relative enabled (ruby-core CI), Gem::Installer generates
wrapper scripts with a bash prolog (#!/bin/sh) when wrappers: true is
set. Bundler's directly_loadable? only recognizes Ruby shebangs, so
these shell wrappers cause "command not found" errors in nested
bundle exec scenarios.

Adding env_shebang: true forces #!/usr/bin/env ruby shebang, which
directly_loadable? recognizes, fixing 6 test failures in ruby-core CI
while keeping wrappers to avoid double-loading issues with symlinks.

ruby/rubygems@e414c5868a

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Gem::Uninstaller with install_dir uses File.realpath for @gem_home but
not for the specification_record path lookup, causing path mismatches
on some CI environments. Instead, temporarily set GEM_HOME and call
Gem.clear_paths to mimic the old subprocess-based gem_command behavior.

ruby/rubygems@14b581725d

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- ### Problem

  I'd like to normalize the number of workers when downloading gems
  and use the `BUNDLE_JOBS` configuration (or default to
  `Etc.nprocessors`).
  Right now the number of workers when doing parallel work seems a bit
  random.

  ### Benchmarks

  **Downloading 40 git gems**

  === Comparison Summary ===

  Scenario: git-gems (40 gems)
                             Cold     +/-                        Warm     +/-
  ------------------------------------------------------------------------------
  more-downloads            7.94s   1.44s  baseline             5.02s   0.31s  baseline
  master                   14.59s   1.67s  83.7% slower         5.72s   0.30s  13.9% slower

  _________________________________

  **Downloading 249 gems from a fake gemserver with a 300ms latency**

  === Comparison Summary ===

  Scenario: no-deps (249 gems)
                             Cold     +/-                        Warm     +/-
  ------------------------------------------------------------------------------
  more-downloads           11.11s   0.66s  baseline             1.23s   0.14s  baseline
  master                   16.89s   0.60s  52.0% slower         1.03s   0.09s  16.2% faster

  ### Context

  I originally added those workers count in

  1. https://github.com/ruby/rubygems/pull/9087/changes#diff-524173391e40a96577540013a1ad749433454155f79aa05c5d0832235b0bdad1R11
  2. https://github.com/ruby/rubygems/pull/9100/changes#diff-04ae823e98259f697c78d2d0b4eab0ced6a83a84a986578703eb2837d6db1a32R1105

  For 1. (downloading gems from Rubygems.org)I opted to go with a
  hardcoded worker count of 5 and not anything higher as I was
  that we could hammer RubyGems.org. I think this concern
  is not valid, because requests to download gems don't even hit
  RubyGems.org server as there is the fastly CDN in front of the s3
  bucket.

  For 2. I went with a worker count of 5 to match, without giving this
  a second thought.

ruby/rubygems@170c9d75c2
- Clarify what `BUNDLE_JOB` is used for and that it affects the
  number of parallel downloads.

ruby/rubygems@36f572b4db
- ### Problem

  For each git gems in a Gemfile a new Git source object is
  instantiated. Each git source will make a system call to check the
  version of git. This is inefficient and we lose ~50ms on each system
  calls.

  ### Solution

  The version of git will not change from one source to the other,
  so we can memoize the value at the class level instead.

ruby/rubygems@1415940a83
@pull pull bot locked and limited conversation to collaborators Mar 18, 2026
@pull pull bot added the ⤵️ pull label Mar 18, 2026
@pull pull bot merged commit 02982ef into turkdevops:master Mar 18, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants