cabo
commented
4 weeks ago The upstream issues are
https://github.com/ruby/rexml/issues/140 https://github.com/ruby/rexml/issues/132 https://github.com/ruby/rexml/issues/131
In https://github.com/ruby/rexml/issues/140, @kou proposes to pin strscan instead (to the version that is included as a default gem in the Ruby version installed). This is better, as it allows the use of a current rexml, and worse, as it needs to be adjusted each time a new Ruby release updates the version of strscan included as default. Since a new Ruby release happens no more than three or four times a year (and not each of of these will update strscan), and the breakage is obvious (simply stopping the update of the docker image), I'd probably go with his recommendation.
The underlying issue is that bundler (reasonably) chooses the most recent revision of a gem, and that may not be the one that is included as a default gem in the ruby version in use -- a compiler run is then needed. A simply gem install does not have the problem and is (after the fix in rexml that had put in a lower bound before) content with the default gem of the installed Ruby version.
The issue is mostly invisible to most maintainers as they are not living under "pure ruby" constraints; the most recent (under certain constraints) revision of a gem is desirable even if it involves native compilation. (This occasionally still comes up as a "Windows issue", because there are additional prerequisites for getting things compiled in Windows.)
It seems that Ruby 3.4.0 (scheduled for 2024-12-25) will create a need to mention even default gems in the gem dependencies, so the fact that bundle does not allow to specify being content with the default gem will create a bigger problem with environments limited to pure ruby installations. Again, a simple gem install is unlikely to create problems.
martinthomson
This is a workaround, but it should work for a while.