On 19 Sep 2007, at 13:03, Michael Koziarski wrote:
It seems to me that it's perfectly possible to depend on the presence of stuff without necessarily patching it (and to be fair a lot of the time you don't need access to your dependencies at plugin load times in which case it all just goes away (which has been the case when we've been using plugins internally to share code between apps) but I wouldn't want to rely on it always working out that easily)."This can be resolved by specifying the load order with theconfig.plugins option, but a user shouldn't have to jump through thosehoops to get things working..."We're still pretty skeptical about plugin dependencies on the whole. Plugins monkeypatching plugins seems like a bit of a recipe for disaster. However we could do something easy like:
Fred
config.plugins = [:gems, :some_kind_of_thing, :all] So you specify the key things at the beginning of the array, then just use :all to mean 'then everything else in alphabetical order'. Seems like that'll solve most of the more-common problems where a specific plugin needs to be early on the load path.On 9/19/07, Pratik <[EMAIL PROTECTED]> wrote:You can actually control the order of plugin loading with config.plugins array, but I'd guess that'd be PITAI believe require_plugin ( I'd prefer just "plugin" ) would be a goodto have feature. On 9/19/07, Andrew Kaspick <[EMAIL PROTECTED]> wrote:Hello all, The topic of plugin dependencies has come up before and it doesn'tseem to have been addressed by core or core doesn't seem to think it's an issue. I've looked at the current edge code and don't see anythingnew, so if I've missed something *please* let me know.The following article makes mention of a require_plugin functionality... http://www.pluginaweek.org/2006/11/05/plugin-dependencies- revisited/and the referenced article seems to make the point that such a featuremay not be required... http://weblog.techno-weenie.net/2006/10/31/plugin-dependencies The reason I bring this up is that with many current core features being moved to plugins, existing plugins that have been written toimprove functionality in some of those core areas may no longer worksince they will now be dependent on these "core plugins" beinginstalled... and even if they are installed, there's no guarantee thatthe load order will be correct.For example, I have written a plugin to improve the functionality of the in_place_editor code. This code works just fine with the current public version of rails. Now in edge this core code has been moved to a plugin and my plugin will no longer work as expected since the core plugin is now "required" by my plugin. This is fine (although a more informational warning would be useful for the user) as the user simplyneeds to install the "core plugin" as well. This is where problems start to occur. Since rails loads plugins in alphabetical order bydefault, if my plugin comes before the core plugin in name, my plugincode is overridden.With many rails features being deprecated and being moved to plugins, this will cause many dependencies on any existing plugins. This canbe resolved by specifying the load order with the config.pluginsoption, but a user shouldn't have to jump through those hoops to getthings working... at least not before a fair amount of possibledebugging since there may be no indication of the underlying problem of an existing plugin not working (a user may believe it's their own code causing problems). Another possible solution is making sure ones own plugin is alpabetically higher than the one it depends on to forcethe proper load order, but that would be rather nasty hack.So I'd like to know what people think about having a "require_plugin" type functionality in core? Is there a valid workaround that existsalready? If there isn't, do people even consider this a problem? Thanks, Andrew-- Cheers! - Pratik http://m.onkey.org-- Cheers Koz --~--~---------~--~----~------------~-------~--~----~You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.To post to this group, send email to [email protected]To unsubscribe from this group, send email to rubyonrails-core- [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/ group/rubyonrails-core?hl=en-~----------~----~----~----~------~----~------~--~---
smime.p7s
Description: S/MIME cryptographic signature
