Hi! I'm one upstream maintainer of rubygems. We've been getting some reports recently from freebsd users about some annoying warnings when using bundler in freebsd. For example: https://github.com/rubygems/rubygems/issues/4283. I investigated the cause, and why only freebsd users have reported this issue. The explanation is that the warning only happens when using bundler in ruby 2.7 in combination with an old rubygems version (the issue was fixed by https://github.com/rubygems/rubygems/commit/2fcde0f4e0153ab9cc2152908bed5b4085d82ce5#diff-8f51ef27aa7c1bf289ef010df42fb4a5f0635d0149776e57bc86985c98bc6480, which was released with rubygems 3.1). In general, we never noticed this because upstream policy is to only support using a rubygems version higher than or equal to the rubygems version included with each upstream ruby version. So the support policy would be: * Ruby 2.5 ships with Rubygems 2.7, so only rubygems versions between 2.7 and the latest rubygems are supported there. * Ruby 2.6 ships with Rubygems 3.0, so only rubygems versions between 3.0 and the latest rubygems are supported there. * Ruby 2.7 ships with Rubygems 3.1, so only rubygems versions between 3.1 and the latest rubygems are supported there. The devel/ruby-gems package follows our policy on ruby 2.5 and 2.6 but ships an out of date rubygems version in the case of ruby 2.7. This causes issues like the one above, since we don't support that combination at all. Would it be possible to get the package upgraded to 3.1.x? Thanks so much!
There is 3.1.5 and 3.2.30, why select 3.1.4 ?
hi, I think it has to do with Ruby 2.7.1 (port lang/ruby27), which printed keyword arguments warnings by default but it was fixed with Ruby 2.7.2 (#250050). If I'm correct, it happened even when using RubyGems (via `gem' command, not bundler calling RubyGems API). The current version of RubyGems is old indeed, some people have worked on the update since a while. From what I experienced and have seen (other PRs on the bug tracker, efforts on other RubyGems ports), the update to 3.1 is a little more involved than some past ones. There is of course the removal of `USE_BUNDLER_FOR_GEMDEPS', but also slightly more changes to the setup command than usual, the repository and history getting bigger, and there are the changes to the plugin system which aren't that big, but whatever solution we chose to adapt the port(s) there are many gems to check (ports of gems which depends on devel/ruby-gems). That may explain some delay. The most recent PR was #258108. However it targets RubyGems 3.2.30 (patches for 3.2.26, 3.2.29, and 3.2.30 attached), because it seemed that most difficulties were related to 3.0 -> 3.1, so once it's done, better use the last one than an old branch I think. Is 3.1 "actively" maintained and should we use that, or keep working on last 3.2? We have Ruby 2.6, 2.7, and 3.0 in ports (maybe 3.1 soon) so it has to work on all of them too. Note: I'm speaking from my point of view of RubyGems user and occasional patch writer or gem porter, not as someone making the actual changes and managing ports in FreeBSD.
Thanks so much for your answers!
I wanted to keep writing but I liked submit too early :sweat_smile: Wen Heping, yes, 3.1.5 would be better, I forgot that we had released one more patch level 3.1 version hehe. Thibault Jouan, thanks so much for the context and for your work. If the upgrade to 3.1 is too hard, and there's already work going on to upgrade to 3.2, then 3.2 is also perfectly fine. While we don't test or consider the scenario of using a rubygems version older than the one shipped with each upstream ruby, we _do_ test the latest rubygems version against all rubies we support, so that should work just fine. And it's also a much better version that 3.1 :) 3.1 is not actively maintained, we have only backported a few fixes so that they can be shipped with further 2.7.x patch level versions of ruby. But nothing other than that. It sounds like https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258108 is quite close to being ready? That would be pretty awesome!
*** Bug 260780 has been marked as a duplicate of this bug. ***
Not a 100% duplicate... *** This bug has been marked as a duplicate of bug 258108 ***