Jean Boussier

> I dumped the heap, was puzzled to see rubocop You mean it's still there even after https://github.com/lobsters/lobsters/commit/47afb301c69799d32f0a1bd0d6568f58f90ff980 ?

One issue though is that Ruby doesn't really have a way to grab all the script arguments to do a re-exec without loosing anything, as evidenced by the failing tests...

Shower thoughts: if we can't re-exec, an alternative could be to do the install in a subprocess. If fork is available it's super simple (albeit a bit unorthodox).

> I think we could vendor securerandom to fix the immediate problem for now, and then introduce this re-execution once usage of original flags is available in Ruby, That would...

> What if `fork` is not available? Don't we have the same "no access to original arguments" issue? I don't think so. If fork isn't available, we can spawn a...

> it should still respect the original ruby flags in the subprocess? Is there any Ruby flag that would have an impact on gem installation?

> In the case of our tests, I think they may complain because of flags that may affect the Bundler code that is loaded, for example, `-I`, or `-r`. Right,...

So I thought about doing this, but the reason I didn't is that I wasn't certain there would be no way left for C extensions to freeze arrays without shrinking...

Wasn't this method private API? I can't find it in https://api.rubyonrails.org/v7.0.0/, if it's not documented (`# :nodoc:`) then is considered private API and can be removed without notice.

Hum, actually somehow the search isn't searching for 7.0, but it was indeed documented: https://api.rubyonrails.org//v7.0.0/classes/ActiveRecord/ConnectionAdapters/AbstractAdapter.html#method-i-schema_cache-3D