Bug #19576
closedBackport request: Gemfile.lock resolving is broken with bundler shipped with Ruby 3.1.4
Description
This is a backport request for bundler, that regressed in 2.3.36 in a specific situation. Newer and older bundler versions that ship with Ruby are not problematic, only the version that ships with Ruby version >= 3.1.3.
A few weeks ago, we discovered a bug in resolving in bundler shipped with Ruby 3.1.3 and 3.1.4:
Bundler version:
$ bundler --version
Bundler version 2.3.26
Affected rubies ruby -v
:
First:
$ ruby -v
ruby 3.1.4p223 (2023-03-30 revision 957bb7cb81) [x86_64-linux]
Second:
$ruby -v
ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux]
Initial bug report with reproducer and more in-depth description can be found here: https://github.com/sclorg/s2i-ruby-container/issues/469
Using the following Gemfile for a rails app:
https://github.com/sclorg/rails-ex/blob/67b7a61eae9efa1088ff3f634ae316e1022fa913/Gemfile.lock
bundler locks up in trying to resolve Nokogiri for Ruby 3.1, but keeps failing because it keeps using incompatible built binary gem instead of falling back to installing and building the binary extension of Nokogiri locally.
We craft this Gemfile to be usable from Ruby 2.5 up to Ruby 3.1, as the app is used mainly for testing.
I have created a patch to fix the situation, see the attached files. There are 2 of them, one contains the fix and the other one contains the test from the rubygems repo PR#6225.
full commit available here: https://src.fedoraproject.org/fork/jackorp/rpms/ruby/c/5ef600a8f40b76de5636dc5e24b75e4e3ff1a87f
The patches are created from the following upstream changes in bundler:
https://github.com/rubygems/rubygems/pull/6225
and adapted:
https://github.com/rubygems/rubygems/commit/7b64c64262a7a980c0eb23b96ea56cf72ea06e89
for the PR#6225.
With the fix applied I no longer have issues doing bundle install
with our Gemfile.lock.
Files
Updated by hsbt (Hiroshi SHIBATA) over 1 year ago
- Status changed from Open to Assigned
- Assignee set to hsbt (Hiroshi SHIBATA)
We need to release Bundler 2.3.27 at first.
Updated by hsbt (Hiroshi SHIBATA) over 1 year ago
I prepared to release new versions with your commits.
Updated by jprokop (Jarek Prokop) over 1 year ago
Thank you. I can confirm that PR fixes what I described in the initial report.
Unfortunately, I recently found second manifestation of this, even with the patch it will fail due to a similar reason of preferring archful gem when deployment
option is set to true
:
$ bundle config set path ./bundle
$ bundle config set deployment true
$ bundle install
Fetching gem metadata from https://rubygems.org/..........
nokogiri-1.12.5-x86_64-linux requires ruby version < 3.1.dev, >= 2.5, which is incompatible with the current version, 3.1.4
I will git bisect
to pin down exactly where it was introduced and where it was fixed in bundler, as, similarly to the inital report, the bug does not appear in newer versions.
Updated by jprokop (Jarek Prokop) over 1 year ago
- File 0001-Backport-Fix-another-issue-of-Bundler-not-falling-back.patch 0001-Backport-Fix-another-issue-of-Bundler-not-falling-back.patch added
With the --deployment option true:
This commit introduced the issue: https://github.com/rubygems/rubygems/commit/09b90646f42a6591c280bbd7484c9bb0aa26b6ae
This commit fixed the issue: https://github.com/rubygems/rubygems/commit/d55ad9b018a585a1b8b0fc324eea531b50de1e19
I have attached a patch that applies on top of the PR https://github.com/rubygems/rubygems/pull/6717
To fix this situation as well.
Tests come attached this time.
Thank you.
Updated by hsbt (Hiroshi SHIBATA) 12 months ago
- Status changed from Assigned to Closed
- Backport changed from 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN to 3.0: DONTNEED, 3.1: REQUIRED, 3.2: DONTNEED
I released RubyGems-3.3.27 and Bundler 2.3.27 for Ruby 3.1.
Updated by hsbt (Hiroshi SHIBATA) 12 months ago
Updated by usa (Usaku NAKAMURA) 12 months ago
- Backport changed from 3.0: DONTNEED, 3.1: REQUIRED, 3.2: DONTNEED to 3.0: DONTNEED, 3.1: DONE, 3.2: DONTNEED
mergerd via GitHub.
thx!