[deps] Update RubyGems to 3.2 and Bundler 2.2#6533
Conversation
|
It would be good to get an update in and baking before we start prepping for 9.3 release. |
|
👍 initially just wanted to check a test run, turns out there's one regression (due) JRuby is guarding with a spec: it "should not create gem subdirectories on a non-file: URL" do
Gem.ensure_gem_subdirectories("classpath:/bogus/classpath")
File.exist?("classpath:/bogus/classpath").should be_false
Gem.ensure_gem_subdirectories("file:")
File.exist?("file:").should be_false
Gem.ensure_gem_subdirectories("uri:file://bogus/classpath")
File.exist?("uri:file:///nothing").should be_false
File.exist?("uri:file://bogus/classpath").should be_false
endspec originated all the way back to: 83dbc63 |
|
seems to be also reproducing a AOT compilation issue (incorrect access modifier?) on the |
|
We sometimes get this error in CI: https://github.com/rubygems/rubygems/pull/3398/checks?check_run_id=1825431461. Could be a similar issue? |
|
@deivid-rodriguez hmm, seems different - while this seemed like a JIT modifier the RGs test case ends up with: could be (JIT) related thought - definitely something worth investigating. |
|
The AOT issue appears to be how AOT scripts are loaded; we are not pushing a new frame for them. In the I would not expect this to affect anyone running JRuby normally. The only script that is AOT compiled under normal circumstances is the main script. |
|
Note that master sets up and loads AOT code differently due to my work on GraalVM Native Image compilation, so it probably does not have the same issue. Merging to master should ignore the |
|
Oh sorry, didn't realize I was pushing to your fork. 🙇♂️ |
|
Is it now fixed? That'd be awesome! I understand that this doesn't affect "normal" usages of jruby, but it does affect our real usage of jruby in our tests, and it's been getting in the middle for a while. If this is fixed, we would no longer have any jruby related flaky failures 🎉. |
|
Funny how I just got a different flaky failure 2 minutes after posting my previous message 🤣. I just got this: https://github.com/rubygems/rubygems/pull/4371/checks?check_run_id=1893310735. |
|
I rerunning CI now to confirm it is a flaky but I'm pretty sure it is because I tend to recall it has happened previously. |
|
@deivid-rodriguez That EAGAIN in waitpid has been fixed on master and backported to 9.2, but that change has not been merged into this branch. See #6477 |
kares
force-pushed
the
rubygems-3.2.5_9.2
branch
from
f95554f to
55a76b3
Compare
|
re-targeted and rebased off master ... let's see how it goes |
|
I see RGs 3.2.6 was pushed since (no need for 55a76b3) |
|
looking good, only 2 (seemingly unrelated) failures from test:jruby suite: |
|
It's 3.2.11 now, actually :) |
kares
changed the title
Great, thanks @headius! That means once the fix is released with the next 9.2.x release and we upgrade our CI, we should be flaky free :) |
|
and we're all 💚 now with latest & greatest RGs 3.2.11, thanks again David for handling the updates JRuby needed! |
kares
changed the title
Here's hoping! 😅 |
|
Should we consider updating 9.2 as well @kares @enebo? RVM at least updates RG anyway, and folks like @deivid-rodriguez have been cranking out bug fixes and updates rapidly over the past year. |
|
👍 happy to re-target back to 9.2 if decided ... CA certificates were updated in RGs 3.2 which might prolong 9.2's ttl the other issue is RGs 3.2 brings Bundler along, JRuby tried shipping Bundler 1.17 in a patch but users did not appreciate - having Bundler 2.x forced on them when they still might use 1.x might present issues, like previously. |
Yeah I will backport that. It was small and low-risk.
Upgrade RG but not ship bundler perhaps, as we have been doing for 9.2? If we want to start shipping bundler with 9.2 we will also need to set it as a default gem and pull in some other default gem fixes (for bin scripts etc) that are only on master. |
We did not need to exclude anything for current RGs shipped with 9.2 - no Bundler packed. |
Ahh, that is a good point. It is pretty annoying that the RubyGems system update shoves bundler into the stdlib rather than just installing it as a gem. If we don't set it up as a default gem on JRuby 9.2, then there's no way to update bundler independently after you have installed it into stdlib (it won't see the gem). Maybe we should just leave well enough alone on 9.2 after all. |
headius
left a comment
headius
left a comment
There was a problem hiding this comment.
Need to remove bundler files and have them installed as part of the build. Bundler must be a default gem in order for it to be upgradable by users.
Rubygems should install bundler as a default gem, can you clarify the question? |
|
If bundler is not getting installed as a default gem by |
|
@deivid-rodriguez Confirmed you are right, Bundler does get installed as a default gem: There is a separate bug with how it generates the |
|
@kares To clarify, it does appear that gem update installs bundler as a default gem. However I don't think we want to version these files. I can see a couple options:
|
|
gem update --system breaks gem binscript on JRuby: ruby/rubygems#4404 |
kares
force-pushed
the
rubygems-3.2.5_9.2
branch
from
049849b to
ffc5dc3
Compare
kares
force-pushed
the
rubygems-3.2.5_9.2
branch
from
80735c1 to
8325747
Compare
kares
force-pushed
the
rubygems-3.2.5_9.2
branch
from
8325747 to
620caa1
Compare
|
Have removed the rubygems files from stdlib (except the JRuby rubygems/defaults). |
kares
changed the title
kares
changed the title
* master: (64 commits) [test] assert same packages regardless of order [test] adjust expected pkg loaded count (due Java 14) [ji] disconnect JavaMethod/JavaConstructor from Ruby land [test] JavaClass.for_name no longer handles JRuby class-path [test] adjust expected messages (now include class name) [test] disable JavaClass.for_name JRuby primitive names [ji] pass around context + handle JavaClass being a proxy [test] some more asserts on JI proxy being unique [refactor] initialize java.lang.Object proxy early yay for regression tests [ji] improve class "not found" message for Ruby error [refactor] assert that java class passed in resolves [fix] need to unwrap Java class proxies now [ji] avoid booting JavaClass (in Ruby land) Update jar-dependencies Update Ruby version to 2.5.8 Update io/console to the gem version Update Rake to match 2.5.8 Consolidate logic. Some times we have a pairs list which is empty and the kwargs rest check was duplicated...no more. Update stdlib from 2.5.8 ...
headius
left a comment
headius
left a comment
There was a problem hiding this comment.
Looks great! Love to see deleted files!
In March 2021 PR jruby#6533 added support for RubyGems to 3.2 and Bundler 2.2 but pinned the versions that were released at the time. This PR was merged into the 9.3.0.0, but this jruby release only happened in September, meaning that JRuby 9.3.0.0 ships with older versions of bundler compared even to JRuby 9.2.
3 participants
UPDATE: this PR removes tracked rubygems sources (except JRuby defaults) and also updates Bundler to 2.2
(this is aligned with
update_rubygemsas RGs 3.2 during update also installs latest Bundler)