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