Make DEFAULT_INSTALL_EXTENSION_IN_LIB to `false` by hsbt · Pull Request #9240 · ruby/rubygems

hsbt · 2026-01-09T03:34:15Z

What is your fix for the problem, implemented in this PR?

install_extension_in_lib leads to install C extension artifacts to under the lib directory.

This makes to hard to share gems across different version of Ruby. We should stop this in the future.

Make sure the following tasks are checked

Describe the problem / feature
Write tests for features and bug fixes
Write code to solve the problem
Make sure you follow the current code style and write meaningful commit messages without tags

Copilot

Pull request overview

This pull request changes the default value of DEFAULT_INSTALL_EXTENSION_IN_LIB from true to false in RubyGems. This change stops installing C extension artifacts to the lib directory by default, making it easier to share gems across different Ruby versions. The change was planned for RubyGems 4.0 (as indicated by the removed TODO comment) and is now being implemented in version 4.1.0.dev.

Key changes:

Changes default behavior for C extension installation location
Removes the TODO comment that indicated this change should happen in RubyGems 4.0

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-01-09T03:36:55Z

  DEFAULT_IPV4_FALLBACK_ENABLED = false
-  # TODO: Use false as default value for this option in RubyGems 4.0
-  DEFAULT_INSTALL_EXTENSION_IN_LIB = true
+  DEFAULT_INSTALL_EXTENSION_IN_LIB = false


The test in test_initialize doesn't verify the default value of install_extension_in_lib when no configuration is provided. Consider adding an assertion like assert_equal false, @cfg.install_extension_in_lib in the first part of the test_initialize method (around line 45) to explicitly test that the new default value is false when no config file setting overrides it.

@copilot open a new pull request to apply changes based on this feedback

Copilot · 2026-01-09T04:01:26Z

@hsbt I've opened a new pull request, #9241, to work on those changes. Once the pull request is ready, I'll request review from you.

…ling extensions into lib directory

…ialize Co-authored-by: hsbt <12301+hsbt@users.noreply.github.com>

rwstauner · 2026-02-23T23:06:47Z

As #8921 suggests, this causes a lot of gems to break at runtime (they install ok, but when loading the app the require fails).

We've patched several gems already after finding issues in CI, but there are many more that will need it:

Are we sure we want to go forward with this?
Was there any plan to contact gem maintainers?
Should we actually recommend configuring install_extension_in_lib: true for deployed installations (where installed gems aren't going to be shared) so that they don't need to wait for new releases of every native extension they use?

hsbt · 2026-02-25T08:50:59Z

@rwstauner Thanks for your work.

Are we sure we want to go forward with this?

Yes, I have no plan to revert this now.

Was there any plan to contact gem maintainers?

I will publish upgrading guide same as https://blog.rubygems.org/2025/12/03/upgrade-to-rubygems-bundler-4.html

Should we actually recommend configuring install_extension_in_lib: true for deployed installations (where installed gems aren't going to be shared) so that they don't need to wait for new releases of every native extension they use?

I think this is necessary for projects that need to continue using gems that are unlikely to be updated, such as sassc.

jhawthorn · 2026-03-02T20:49:53Z

While I agree we probably shouldn't install to lib (and I also don't like the default use of require_relative), this will break any native extension created using the default template in the last 6 years (everything between #4066 and #9156). That's a pretty extreme compatibility issue with no advance notice.

This pull request changes the native extension loading from `require_relative` to `require` to ensure compatibility with the latest RubyGems, which no longer installs native extensions into the gem's `lib/` directory by default. See ruby/rubygems#9240. Using `require` resolves the extension through `$LOAD_PATH`, which RubyGems populates with both the `lib/` and extension directories, so this works on both old and new versions of RubyGems. Resolves #1244 Co-Authored-By: Daniel Colson <composerinteralia@github.com>

RubyGems is changing `install_extension_in_lib` to default to false (ruby/rubygems#9240), meaning native extensions will no longer be installed into `lib/`. `require_relative` won't be able to find the shared object, but `require` will since RubyGems adds the extension directory to the load path.

hsbt · 2026-03-12T00:55:01Z

@jhawthorn Initially, I wondered why the C extension was require_relative, but after reading #9240 (comment), I realized that we was using require_relative for a C extension in a template.

I'll also look into ways to restore settings and warn about this issue with rake build, etc. Thanks for your pointing out.

…ut bug RubyGems 4 stopped copying .so files into lib/ (ruby/rubygems#9240), and Bundler 2.5.x doesn't properly resolve the new extension directory layout, causing LoadError for native gems like bigdecimal. Document the workaround (upgrade Bundler + bust CI cache) and note the Bundler version requirement for Ruby 4.0 users.

Copilot AI review requested due to automatic review settings January 9, 2026 03:34

hsbt changed the title ~~Make DEFAULT_INSTALL_EXTENSION_IN_LIB false by default to stop instal…~~ Make DEFAULT_INSTALL_EXTENSION_IN_LIB to false Jan 9, 2026

Copilot started reviewing on behalf of hsbt January 9, 2026 03:34 View session

Copilot AI reviewed Jan 9, 2026

View reviewed changes

Copilot AI mentioned this pull request Jan 9, 2026

Add test assertion for install_extension_in_lib default value #9241

Merged

4 tasks

hsbt added the rubygems: breaking change label Jan 9, 2026

hsbt force-pushed the disable-to-install-extension-lib branch from 8eaf071 to bcc9e0d Compare January 26, 2026 06:51

hsbt and others added 2 commits February 13, 2026 09:07

Make DEFAULT_INSTALL_EXTENSION_IN_LIB false by default to stop instal…

1614b03

…ling extensions into lib directory

Add assertion for install_extension_in_lib default value in test_init…

cf8c9ee

…ialize Co-authored-by: hsbt <12301+hsbt@users.noreply.github.com>

hsbt force-pushed the disable-to-install-extension-lib branch from bcc9e0d to cf8c9ee Compare February 13, 2026 00:07

hsbt enabled auto-merge February 13, 2026 00:07

hsbt merged commit a8fb835 into master Feb 13, 2026
95 of 97 checks passed

hsbt deleted the disable-to-install-extension-lib branch February 13, 2026 00:59

composerinteralia mentioned this pull request Feb 25, 2026

Using require_relative for the extension is not compatible with latest rubygems marcoroth/herb#1244

Closed

marcoroth mentioned this pull request Mar 3, 2026

Ruby: Fix native extension loading for new RubyGems (Ruby 4.1+) marcoroth/herb#1281

Merged

jhawthorn mentioned this pull request Mar 6, 2026

Use require instead of require_relative for native extension jhawthorn/ractor_safe#1

Merged

jhawthorn mentioned this pull request Mar 6, 2026

Use require instead of require_relative for native extension jhawthorn/json_escape#3

Merged

jhawthorn mentioned this pull request Mar 6, 2026

Use require instead of require_relative for native extension jhawthorn/rbdbg#1

Merged

jhawthorn mentioned this pull request Mar 6, 2026

Use require instead of require_relative for native extension jhawthorn/unsafe#1

Merged

hsbt mentioned this pull request Mar 12, 2026

Revert DEFAULT_INSTALL_EXTENSION_IN_LIB and warn require_relative with C ext #9390

Merged

4 tasks

Thejus-Paul mentioned this pull request Mar 31, 2026

docs: add troubleshooting for Bundler 2.5.x + Ruby 4.0 extension layout bug gembakery/prebake#20

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Make DEFAULT_INSTALL_EXTENSION_IN_LIB to `false`#9240

Make DEFAULT_INSTALL_EXTENSION_IN_LIB to `false`#9240
hsbt merged 2 commits intomasterfrom
disable-to-install-extension-lib

hsbt commented Jan 9, 2026 •

edited

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Jan 9, 2026

Uh oh!

hsbt Jan 9, 2026

Uh oh!

Copilot AI commented Jan 9, 2026

Uh oh!

Uh oh!

rwstauner commented Feb 23, 2026

Uh oh!

hsbt commented Feb 25, 2026 •

edited

Loading

Uh oh!

jhawthorn commented Mar 2, 2026

Uh oh!

hsbt commented Mar 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Conversation

hsbt commented Jan 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What is your fix for the problem, implemented in this PR?

Make sure the following tasks are checked

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Jan 9, 2026

Choose a reason for hiding this comment

Uh oh!

hsbt Jan 9, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI commented Jan 9, 2026

Uh oh!

Uh oh!

rwstauner commented Feb 23, 2026

Uh oh!

hsbt commented Feb 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jhawthorn commented Mar 2, 2026

Uh oh!

hsbt commented Mar 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

hsbt commented Jan 9, 2026 •

edited

Loading

hsbt commented Feb 25, 2026 •

edited

Loading