[Rubygems-developers] Status of disabling plugins except for command line?
Charles Oliver Nutter
headius at headius.com
Thu Dec 23 14:00:40 EST 2010
On Thu, Dec 23, 2010 at 9:55 AM, Trans <transfire at gmail.com> wrote:
> On Dec 23, 4:24 am, Charles Oliver Nutter <head... at headius.com> wrote:
> The two I know of are gem-wedge and ore.
> Ore is especially ironic, b/c I was recently told that RubyGems did
> not need to support plain YAML specs itself b/c a plugin, like Ore,
> could do the job.
How does this break them?
> Doesn't the file system itself cache the file access, so after the
> first run it speeds up for every subsequent use? So it's not quite
> that bad. But to be sure I am not against fixing this, I just don't
> want to see non-command plugins broken to do it.
Yes it does. With 500+ gems the uncached startup time on JRuby was 17
seconds. Cached time went down to 6.9. Without plugin scanning, under
half a second. I consider that pretty bad, even cached.
> A real solution would check for a plugins at install time, if one is
> found copy it to a special location, e.g. gems/plugins, in much the
> same way that a gem's specification is copied to a special location.
> Then when Rubygems is loaded there is no need to search the file
> system, all the plugins are in one place.
Agreed. That doesn't seem like something that can land in the short
term. This is a very clean, very light patch for a magnificent
improvement, at the cost of a handful of plugins. And depending on how
they break, the workaround could simply be to require 'gem_runner' (or
to create a new "plugins.rb" with the plugin-loading logic, and then
the workaround is to require that).
More information about the Rubygems-developers