Sebastian Schuberth

BTW, this is for PI version 0.10.0 which we're still stuck on due to [this regression](https://github.com/aboutcode-org/python-inspector/issues/173).

As @mnonnenmacher found out, this seemingly is related to [setuptools 75.0.0](https://setuptools.pypa.io/en/latest/history.html#v75-0-0) adding `jaraco.collections`.

Not sure how helpful it is, but this is where it throws: 

The last call in AsciidoctorJ before entering JRuby seems to be: ```java private void preloadLibrary(String option) { this.rubyRuntime.evalScriptlet(optionToRequiredGem.get(option)); } ```

Note that JRuby 10 has a minimum requirement of Java 21 now, which is incompatible with AsciidoctorJ's minimum requirement of Java 11. So this issue might be similar to https://github.com/asciidoctor/asciidoctorj/issues/1285...

Not sure how, but for me (while sticking to JRuby 10.0.2.0) the [upgrade of AsciidoctorJ-PDF from 2.3.19 to 2.3.20](https://github.com/asciidoctor/asciidoctorj-pdf/compare/v2.3.19...v2.3.20) seems to have fixed the issue.

Looks like the GraalPy team does something similar already: https://mvnrepository.com/artifact/org.graalvm.python/python-launcher. I guess it makes sense to align here in terms of user experience.

Some example commands are `pod --version` or `pod repo add-cdn trunk https://cdn.cocoapods.org --allow-root`.

> So at least these 3 `pod` commands don't need a `bin/ruby` launcher. but installing the gem needs it. What "magic" does the `bin/ruby` launcher script do on top of...

> I think using `RubyLauncher` won't work for such a use case, because it always does `System.exit(exitCode)` Good point. I guess that could easily worked around by naively moving all...