[Rubygems-developers] Status of disabling plugins except for command line?
transfire at gmail.com
Thu Dec 23 13:21:15 EST 2010
On Dec 23, 11:48 am, James Tucker <jftuc... at gmail.com> wrote:
> Ore doesn't contain a rubygems_plugin.rb. Dude, come on.
I am not sure how postmodern utilizes this, and there may be a work
around here too, but nonetheless it's not a "spectre" ;)
> When I looked at wedge, I figured it was largely experimental and not widely used. It's hooks can also be installed elsehow (that is, by having the application load it - the same way bundler and isolate do). If you want to avoid that, you could add -rwedge to RUBYOPT.
Hmm.. it's not really a per-application kind of thing, but the later
idea might work.... well yea obviously b/c then we're basically
setting up an explicit plugin for Ruby itself. Maybe not as convenient
as the gem plugin, but perhaps better for being more explicit. I'll
play around with that and see how it goes, thanks.
> Actually, I've seen more bug reports from broken plugins forcing people to manually remove gems and/or reinstall everything than I have seen usage of non-command plugins. Bear in mind that I've been both following the tracker, and diving through /all gems/ as my research.
Reinstall everything? How would a plugin cause that? Eek. In any case,
I would think command plugins are just as prone to error as any
> > 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.
> That's actually not quite enough. These problems have nasty edge cases:
> Many plugins use File.expand_path to load their other parts, because we don't activate plugins.
> We should not be loading multiple versions of a single plugin.
> What should be the policy when a newer gem is installed that does not contain a plugin, but an older version does contain a plugin? This can lead to unresolvable problems.
> We need options to turn the features off in future.
> This is all in my long term plan. We're not alienating anyone by this change, and people have been trying it out in the wild for a good deal of time too, as well as I've been watching and researching it.
Yep, I understand on all accounts. Just would be nice to go head and
do the long term plan and get it done. Things may not be prefect as
is, but we've been working with it as is for a while now and getting
Recently I was toying with the idea of extend Bundler's Gemfile. But
Bundler has no plugin system, so I wasn't sure how I could make it
work. Then I realized I could use rubygems plugin system b/c Bundler
depends on Rubygems. I tried it and it worked fine. This was just
experimental, as I said, but I think it's a good example of
possibilities that might be limited.
More information about the Rubygems-developers