[ruby/irb] Don't lazily retrieve gem specs for completion
There are a few downsides of the current approach:
Because gem specs are lazily retrieved, this computation happens in
every irb completion test case, which is not necessary. (In tests we
don't cache the result of retrieve_files_to_require_from_load_path)
Gem::Specification.latest_specs is sensible to the content of
LOAD_PATH. And when combined with 1, tests fail "randomly" if they
try to mutate LOAD_PATH, even though the test subject it's something
else.
So by pre-computing and storing the gem paths in a constant, it guarantees
that the computation only happens once and it doesn't get affected by test
cases.
One argument could be made against the change is that, it'll store
unnecessary data for users that disable autocompletion. But the
counter-arguments are:
Since autocompletion is enabled by default, this should not be the
case for most users.
For users with autocompletion enabled, IRB already caches the
result of retrieve_files_to_require_from_load_path in memory, which
should have a similar size of GEM_SPECS. And we currently haven't
received any report about problems caused by such memory consumption.
[ruby/irb] Don't lazily retrieve gem specs for completion
There are a few downsides of the current approach:
every irb completion test case, which is not necessary. (In tests we
don't cache the result of
retrieve_files_to_require_from_load_path)LOAD_PATH. And when combined with 1, tests fail "randomly" if they
try to mutate LOAD_PATH, even though the test subject it's something
else.
So by pre-computing and storing the gem paths in a constant, it guarantees
that the computation only happens once and it doesn't get affected by test
cases.
One argument could be made against the change is that, it'll store
unnecessary data for users that disable autocompletion. But the
counter-arguments are:
case for most users.
result of
retrieve_files_to_require_from_load_pathin memory, whichshould have a similar size of GEM_SPECS. And we currently haven't
received any report about problems caused by such memory consumption.
https://github.com/ruby/irb/commit/c671d39020