[Rubygems-developers] Status of disabling plugins except for command line?

Trans transfire at gmail.com
Thu Dec 23 10:55:27 EST 2010

On Dec 23, 4:24 am, Charles Oliver Nutter <head... at headius.com> wrote:
> On Thu, Dec 23, 2010 at 3:08 AM, Trans <transf... at gmail.com> wrote:
> > I know of at least two gems it will break, and I suspect they are not
> > your four.
> You guys with your mystery lists. Spill it, man!

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.

> > I thought RubyGems was supposed to be so *conservative* about changes,
> > and here a change is just going to be pushed that breaks people's
> > plugins for the sake of a speed up for those who have 500+ gems
> > installed?
> It's not just a problem for 500+, it's a problem for anyone who
> installs, say, Rails 3's several dozen dependencies. Globbing through
> all those directories gets linearly slower, and even people with just
> a few gems will notice a startup improvement from this.
> The right answer is that plugins should NEVER have been
> auto-discovered with a filesystem scan on every startup since that's
> inherently O(N) as more gems are introduced (and especially bad on
> implementations that already have startup concerns like JRuby or
> Rubinius).

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.

> So I feel more like we're righting an over-eager change
> (plugins scanned on every load of 'rubygems') by backing off the most
> egregious aspect of that decision. We're not breaking good behavior,
> we're rolling back bad behavior. I call that a bug fix.

One man's bug is another man's feature ;)

> > Overlooking the fact that there other solutions to deal with large gem
> > collections, like rvm's gemsets. Why wouldn't the prudent course of
> > action be to actually fix this _correctly now_, rather than implement
> > a "phase 1" change that will leave certain types of plugins out in the
> > cold for who knows how long?
> > If that's asking too much, then at the very least, make this patch a
> > configurable option in the .gemrc file. Power users who aren't using
> > any of the above mentioned plugins could then easily flip the switch
> > to get the speed up.
> No plugins have been mentioned :) All I see are shadows and spectres.
> I want to know what these plugins are and why this change breaks them.
> If there's additional changes required to keep them working, we can
> discuss that. But having a simple load of 'rubygems' scan the
> filesystem every freaking time is a nonstarter (and should always have
> been).

No, it was a shortcut then, and now another shortcut is being made to
remedy the first.

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.

More information about the Rubygems-developers mailing list