[Rubygems-developers] Status of disabling plugins except for command line?
jftucker at gmail.com
Thu Dec 23 14:14:24 EST 2010
On Dec 23, 2010, at 1:21 PM, Trans wrote:
> 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" ;)
I looked in the wrong repo. My bad.
This code doesn't seem to modify rubygems at all, and doesn't need to be a rubygems plugin as far as I can see.
>> 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.
I do later want to add hooks for the rest of this, but that'll be as time allows.
>> 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
raise 'boom' in rubygems_plugin.rb
Real world cases of this came up with older versions of gemcutter plugins.
Many users don't know how to manually uninstall gems, so their response (when they can't find help) is to reinstall their ruby + rubygems.
>>> 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
Agreed, that would be nice, I've just run out of time, and people have been asking me for months now. I think it's fair to go with the commonly made demands and fix common problems, than to wait for my time to become available. The balance tips toward those folks with problems, which are more numerous than those we affect, especially in light of available workarounds.
> 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.
The Gemfile is an instance_eval. You can extend it like so:
Among other ways.
More information about the Rubygems-developers