Are plugins still necessary in Rails3?

I wanted to get the conversation started...what do people think?

http://pivotallabs.com/users/mgehard/blog/articles/1499

I wanted to get the conversation started...what do people think?

Bundler's certainly done a great job of making it low-cost to add, install and upgrade gems that your app depends on. However without a pretty compelling *cost* to maintaining the existence of plugins, I don't really see what the upside is.

For the odd small snippet of code you want to share amongst a few applications, plugins are a lovely lo-fi solution. Removing that would come with a pretty high hurdle, one much higher than "the code would be nicer" when, in reality, it's very little code to support them, 91 lines or so at present.

Bundler's certainly done a great job of making it low-cost to add, install and upgrade gems that your app depends on. However without a pretty compelling *cost* to maintaining the existence of plugins, I don't really see what the upside is.

I think there's a compelling cost in *using* plugins. If plugins were no longer supported, developers would be forced to build gems. As it is, every project I work on seems to have one or two plugins that won't make the switch. Maintaining them as submodules or some other oft-horrific process is costly compared to the ease of gems and bundler.

For the odd small snippet of code you want to share amongst a few applications, plugins are a lovely lo-fi solution. Removing that would come with a pretty high hurdle, one much higher than "the code would be nicer" when, in reality, it's very little code to support them, 91 lines or so at present.

It's really, really easy to make a gem. And it clarifies your code structure. It makes it easier to test properly. And with bundler, you don't even need to publish the gem anywhere. You can host it privately with git, and you can develop locally without bumping the gem version or even "bundle update"ing between changes.

If you're sharing anything between your apps, you benefit from using a gem. It's easier than git submodules or any equivalent. The only way a plugin is easier to manage (in my experience) is if you're just copying it in and not backing it with its own source control. And let's hope no poor souls are doing that. And if they insist, they still have the lib directory.

You're right: 91 lines isn't much to maintain. But that's not the cost that concerns me.

Peter

On the good side of keeping plugins, unless I'm missing something, it seems easier for the developer to test (I'm not talking about automated tests) the plugin in the development phase, before packaging it in a gem. But maybe I'm just missing about how development could be easily tested when used as a gem...

Rodrigo

I wanted to get the conversation started…what do people think? Bundler’s certainly done a great job of making it low-cost to add,

install and upgrade gems that your app depends on. However without a

pretty compelling cost to maintaining the existence of plugins, I

don’t really see what the upside is.

For the odd small snippet of code you want to share amongst a few

applications, plugins are a lovely lo-fi solution. Removing that

would come with a pretty high hurdle, one much higher than "the code

would be nicer" when, in reality, it’s very little code to support

them, 91 lines or so at present

On the good side of keeping plugins, unless I’m missing something, it seems easier for the developer to test (I’m not talking about automated tests) the plugin in the development phase, before packaging it in a gem. But maybe I’m just missing about how development could be easily tested when used as a gem…

With bundler you can test your gem in development easily, just use :path in your Gemfile:

gem ‘xxx’, :path => ‘your local folder’

Jan

Or even easier:

Gemfile

gemspec

Yehuda Katz Architect | Strobe (ph) 718.877.1325

I think there's a compelling cost in *using* plugins. If plugins were no longer supported, developers would be forced to build gems. As it is, every project I work on seems to have one or two plugins that won't make the switch. Maintaining them as submodules or some other oft-horrific process is costly compared to the ease of gems and bundler.

Plugins which aren't being maintained wouldn't magically have been maintained if the authors had been told to use gems instead of plugins. Your application upgrade process would have been just as hard there with a gem which wasn't updated as it was

If you're sharing anything between your apps, you benefit from using a gem. It's easier than git submodules or any equivalent. The only way a plugin is easier to manage (in my experience) is if you're just copying it in and not backing it with its own source control. And let's hope no poor souls are doing that. And if they insist, they still have the lib directory.

The lib directory doesn't give you an init.rb which is automatically required at the right moment.

I'm all for de-emphasing plugins maybe. Removing the plugin generator, putting gems first in guides. But that's something else entirely for someone who just wants to dump a monkeypatch into their app.

What about this scenario.

You use Rails and have several developers working on the project. You have several environments and lots of machines in each one.

Plugins are great since you don't have to put on your "Ops" hat and alter your chef recipes (if you even have automated build scripts) so you can update gems on all the machines. In addition not all developers will have access to install gems on machines so plugins can alleviate some of this headache.

My main gripe about plugins as noted above, (besides the slow start time) is keeping them updated, especially if you patch them for a bug fix or some customization.

So I agree with the gripes but I still find them very useful.

Yeah, I buy that. Count my vote toward deprecating the plugin system. Let's not do anything to encourage new plugins to be made. But sure, no harm in letting them function until the plugin code becomes a thorn in our side someday.

Peter

Sorry, mr Yoda, I didn’t get. I read about the ‘#gemspec’ command in the Gemfile description here:

[http://gembundler.com/man/gemfile.5.html](http://gembundler.com/man/gemfile.5.html)

Still, I can't understand very well what you are suggesting,

although I can understand Jan’s approach.

Anyway, I didn't test it, but are the gem sources reloaded in

development mode as when developing a plugin when using either approach (#gemspec or ‘gem “xxx”, path: “…/mygem”’)?

Personally, I have no reason to use plugins anymore. Bundler has made this a moot point.

However, I spend a lot of time teaching Rails, and (unfortunately) many people don't have git installed, and it frankly doesn't make sense for them to just for the :git option in a Gemfile. I think we need a quick way to install gems/plugins without requiring git before we can fully rely on bundler. Maybe a new form of script/plugin install that just adds an appropriate line to the Gemfile with :path would suffice. It would make it easier for the newcomers.

The last couple times I've taught, showing off plugins has seemed a bit archaic. In the absence of git, however, they are still easier than any alternatives.

As a start, I do like the idea of rewriting the Plugins guide to emphasize the creation of a gem for an extension but still give the option (way down at the bottom) of writing a plugin. It might also be nice to give some instructions on how to convert a plugin to a gem.

This will get people thinking in the right direction. Then when the plugin code becomes a thorn in Rails' side it will be easier to remove.

I will volunteer to help rewrite the Guide to emphasize the gem creation and put something in about upgrading plugins to gems.

I agree we should de-emphasize plugins, but continue to support them.

Besides changing the guides, the generator should create plugins that are on the road to becoming gems. The concept being that you are creating an "unpolished gem" more than a "plugin". If we make it easy to take that final step to get to a gem, plugins will fade away.

Here are my suggestions: 1. put default Gem::Specification and Rake::GemPackageTask in the Rakefile 2. generate rails/init.rb, Gemfile, and maybe even .gemspec 3. stop generating install.rb and uninstall.rb 4. change "rails generate plugin ..." to "rails generate gem ..." (and add a deprecation notice on "rails generate plugin")

In a related tangent, I also wonder whether the lower-profile of plugins has caused vendor/* to lose its usefulness. Could everything in vendor/ move to lib/? It might just require some tweaks the autoloaded paths. lib/ could become the single directory for storing all non-application, non-Bundler, libraries of code.

I find vendor to be a nice conventional place for various files that our applications depend on, which should be version controlled alongside our ruby code. The contents of vendor may not even be ruby -- it might contain supporting software that's used in an integration, for instance.

Put another way, vendor is the place for third-party (vendor) support files.

I agree. ./lib is mine, ./vendor is 'theirs'.

Full support with me on slowly deprecating the plugin system. It saves new developers the cognitive load of asking "plugin vs gem".

@Kevin

Great idea with the "rails generate gem" addition.

Bundler comes with a gem generator:

bundle gem <gemname>

Looks like someone has started to move down the gem route...

https://github.com/rails/rails/commits/master/railties/lib/rails/generators/rails/plugin_new

Hey,

Indeed, I started work on that, mainly because of mountable applications (engines), but it can be used to generate any kind of rails extension. It's based on http://github.com/josevalim/enginex and the key difference in comparison to older plugins generator is that dummy application is generated in test/dummy (it can be configured with --dummy-path). This application is used to run the tests or during development to run server or console.

Cheers, Piotr