Right now, an off-the-shelf irb install is entirely broken on jruby 10+, due to ruby/rdoc#1746 and (arguably) the lack of constraints on irb’s dependencies. Yes, perhaps it will install again soon when/if a WASM jruby variant of rdoc/rbs is released, but that seems partly besides the point of whether irb should break like this in ways that pushes effort to users or other library maintainers.
Upstream
In lieu of implementing #1211 or some variant, my observation is that the dependency tree for irb (which is still on 1.x theoretically, yet is seeing a surprising amount of dependency churn) is getting increasingly complex and “chunky” over time, especially in ways that affect jruby, or any application that needs to keep its CRuby extensions under control (for which there are a number of reasons to do so, including build time, use of uncommon architectures, lack of precompiled extensions for a given CRuby version and architecture, security concerns etc). Earlier it was issues with psych or erb and their Java extensions (also via rdoc) causing compatibility issues with various jruby versions - now it’s rbs (also via rdoc).
Downstresm
While it is not irb’s “fault”, irb is also now an unconstrained runtime dependency of railties, meaning every rails installation is now getting it (in production environments despite it being an “interactive” library, no less) and rdoc…plus rdoc’s entire dependency tree which now includes rbs… which includes prism, erb, tsort and… you get the idea. (For reference rdoc was zero dependencies at 6.3.0 in 2021)
Bundler challenges
This increasingly forces users to keep digging into their transitive trees to debug problems disconnected from what they are actually using (which might be rails or something else further up the stack). Given bundler’s inability to express optional dependencies or transitive constraints (I think?) this makes lives of library maintainers even tougher when testing across versions and implementations, and trying to keep compatible sets of versions in ways bundler should be able to express for them, or which libraries should possibly be more conservative with.
Next steps
I understand jruby might not be a priority, and that this may be ignored or closed as “won’t fix” - however I also think some more consideration could go into how heavy the dependency tree is and what risk and version interoperability problems it brings. Mainly rdoc.
In the short term, to directly resolve this issue, with such a dependency tree, it doesn’t seem good practice to me to have an unconstrained rdoc dependency that isn’t specifically validated with irb across impls important to the ecosystem. Medium term, I’d ask to consider whether irb is appropriately modularised in ways that are sufficiently easy to work with via bundler.
Right now, an off-the-shelf irb install is entirely broken on jruby 10+, due to ruby/rdoc#1746 and (arguably) the lack of constraints on irb’s dependencies. Yes, perhaps it will install again soon when/if a WASM jruby variant of rdoc/rbs is released, but that seems partly besides the point of whether irb should break like this in ways that pushes effort to users or other library maintainers.
Upstream
In lieu of implementing #1211 or some variant, my observation is that the dependency tree for irb (which is still on 1.x theoretically, yet is seeing a surprising amount of dependency churn) is getting increasingly complex and “chunky” over time, especially in ways that affect jruby, or any application that needs to keep its CRuby extensions under control (for which there are a number of reasons to do so, including build time, use of uncommon architectures, lack of precompiled extensions for a given CRuby version and architecture, security concerns etc). Earlier it was issues with psych or erb and their Java extensions (also via rdoc) causing compatibility issues with various jruby versions - now it’s rbs (also via rdoc).
Downstresm
While it is not irb’s “fault”, irb is also now an unconstrained runtime dependency of railties, meaning every rails installation is now getting it (in production environments despite it being an “interactive” library, no less) and rdoc…plus rdoc’s entire dependency tree which now includes rbs… which includes prism, erb, tsort and… you get the idea. (For reference rdoc was zero dependencies at 6.3.0 in 2021)
Bundler challenges
This increasingly forces users to keep digging into their transitive trees to debug problems disconnected from what they are actually using (which might be rails or something else further up the stack). Given bundler’s inability to express optional dependencies or transitive constraints (I think?) this makes lives of library maintainers even tougher when testing across versions and implementations, and trying to keep compatible sets of versions in ways bundler should be able to express for them, or which libraries should possibly be more conservative with.
Next steps
I understand jruby might not be a priority, and that this may be ignored or closed as “won’t fix” - however I also think some more consideration could go into how heavy the dependency tree is and what risk and version interoperability problems it brings. Mainly rdoc.
In the short term, to directly resolve this issue, with such a dependency tree, it doesn’t seem good practice to me to have an unconstrained rdoc dependency that isn’t specifically validated with irb across impls important to the ecosystem. Medium term, I’d ask to consider whether irb is appropriately modularised in ways that are sufficiently easy to work with via bundler.