Allow plugins to be reloadable simply by moving them to vendor/plugins/reloadable/

Patch for making a plugin reloadable by putting it into vendor/plugins/reloadable/

I guess it should go to Railties (based on http://dev.rubyonrails.org/changeset/5801)

I'm not really keen on using the filesystem to indicate whether or not plugin code should be reloadable - perhaps there's something else at the core of this issue?

I'd suggest that plugin code reloading is only really an issue when someone is developing plugins, rather than in all development environments. Does that seem fair?

Perhaps a flag or configuration which would disable "load_once_paths" when necessary or useful might be a better approach? It would also be worth exploring why "load_once_paths" exist in the first place.

This is an issue when using engines, which isn't really plugin development, although technically your code resides in vendor/plugins. But you're using it as a way to share code between applications, an 'acceptable' use of engines/plugins. It's a major PITA when your plugin code doesn't reload.

When you say "using engines" I understand you to mean "developing plugins", because there's no difference between an "engine" and a "plugin" now, and reloading is only signficant - unless I'm misunderstanding you - when you are making changes to that plugin, i.e. when you are developing. When the application is running in production (regardless of what plugins are installed/active) reloading isn't desirable.

Can you explain your motivations here with a concrete example that we could use to discuss it further?

The difference is in practice. Some plugins (and engines I guess) are developed once, and left alone. However, a substantial amount of our development goes into engines so that we can share the code.

So say we have a bunch of human resources by models (Person, Permission, PersonPermission) which we want to use on a bunch of different apps (so you can use single signon, one permissions-managements app, etc). We use vendor/plugins/common_models/app/models/Person.rb etc.

An alternative was to use svn externals. For example, app/models/common_models -> svn repo for common models. But we decided that would be more of a mess; with engines they are at least grouped in one spot. For example if we wanted to use some common controllers, we would have to do another external in the app/controllers folder. If we wanted to then mix in controllers, we'd have to make sure the paths are being loaded right and figure out namespace. I'm sure it could be made to work, but engines seemed like the nicer solution.

So to address your first comment on the difference between engine/plugin, yes it is a plugin, but we "develop" it all the time because it's a core part of our app, because we use engines as a code sharing mechanism. So reloadable plugins stuff is really important and makes our development much nicer.

I can completely sympathize with your development pain, but there may be other ways around this, rather than using the filesystem. A few ideas could be:

• Use require_dependency to register your file with the Dependencies' reloading mechanism, rather than the magical constant autoloading:

require_dependency "some_class_in_a_plugin"

class PluginController < ApplicationController
  def action
    # ...

• Add an after_initialize hook in your development environment:

config.after_initialize {
  Dependencies.load_once_paths = []
}

Either of these should allow you to edit code in plugins and have it reload without needing to make any changes to your plugin layout. The tradeoff is, of course, an imperceptibly minor performance hit in development mode as your files are reloaded after each request, but I trust that's an acceptable price to pay for making your development process less painful; HTH - if that resolves your issue, please do close this ticket with the appropriate resolution.

Closing this ticket, since there's been no word on it since last December.