[Rubygems-developers] Status of disabling plugins except for command line?
jftucker at gmail.com
Wed Dec 22 22:46:12 EST 2010
On Dec 22, 2010, at 5:56 PM, Charles Oliver Nutter wrote:
> On Wed, Dec 22, 2010 at 1:33 PM, Charles Oliver Nutter
> <headius at headius.com> wrote:
>> Here's my naïve change and the impact to perf with around 500 installed gems:
> A note of clarification... the first two times there are without the
> patch (obviously), and the first time is with an uncached filesystem
> (cold). So you kinda can see worst and best-case performance scanning
> 500 gems for plugins under JRuby.
> 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.
Some more details:
- This is kind of the phase 1 plan, although if there was more time available I've had avoided doing this.
- 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.
- There have been no objections so far except from Erik Hollensbe, I think it's related to his recent gem testing plugin. We can provide hooks for him in a future version.
- Which brings me to phase 2:
* Plugins should actually activate the gems they're loaded from (otherwise we have double-loads double versions, blah blah)
* Plugin files should have a way to hook without actually /loading code/. (f.e. "load me before running commands")
* Plugin file locations should be cached separately to avoid having to walk the source index. This index should only include the 'latest gem' for each gem containing a plugin. It would be updated on install and uninstall.
* Plugin loading must have a generic --no-plugins option in the gem command, so that broken plugins don't require manual removal.
More information about the Rubygems-developers