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

Trans transfire at gmail.com
Thu Dec 23 04:08:18 EST 2010



On Dec 22, 10:46 pm, James Tucker <jftuc... at gmail.com> wrote:
> On Dec 22, 2010, at 5:56 PM, Charles Oliver Nutter wrote:
>
> > On Wed, Dec 22, 2010 at 1:33 PM, Charles Oliver Nutter
> > <head... at headius.com> wrote:
> >> Here's my naïve change and the impact to perf with around 500 installed gems:
>
> >>https://gist.github.com/751969
>
> > I'm guessing there's also potential fixes for that scanning process,
> > all the way up to caching lists plugins on install (i.e. eliminating
> > future scans altogether), but this is a good quick fix for
> > non-command-line rubygems use.
>
> +1 on this patch for now.

-1 _for now_.

>  - This will break 4 gem plugins, mostly minor and I've never seen them used 'in the wild'. I have the list knocking around somewhere, I'll dig it up if someone reminds me when I'm awake.

I know of at least two gems it will break, and I suspect they are not
your four.

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?

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.



More information about the Rubygems-developers mailing list