On Thu, Dec 23, 2010 at 3:08 AM, Trans <transf...@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! > 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). 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. > 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). - Charlie _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
