Are plugins still necessary in Rails3?
PivotalBoulderMikeG
http://pivotallabs.com/users/mgehard/blog/articles/1499
Michael Koziarski
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.
--
Cheers
Koz
Rodrigo Rosenfeld Rosas
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
Peter Jaros
> 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.
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.
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
Jan
Rodrigo
--
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 rubyonra...@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Yehuda Katz
Michael Koziarski
> 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.
>
> You're right: 91 lines isn't much to maintain. But that's not the
> cost that concerns me.
>
> Peter
>
> --
> 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 rubyonra...@googlegroups.com.
> To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
>
>
--
Cheers
Koz
Peter Jaros
<mic...@koziarski.com> wrote:
> 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.
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
jocmaff
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.
Rodrigo Rosenfeld Rosas
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"')?
Daniel Morrison
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.
PivotalBoulderMikeG
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.
Kevin Skoglund
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.
Ernie Miller
> 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.
--
Ernie Miller
http://metautonomo.us
http://github.com/ernie
http://twitter.com/erniemiller
James B. Byrne
On Wed, December 8, 2010 11:31, Ernie Miller wrote:
> On Dec 8, 2010, at 11:22 AM, Kevin Skoglund wrote:
>> 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'.
--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:Byr...@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
Jack Kinsella
new developers the cognitive load of asking "plugin vs gem".
@Kevin
Great idea with the "rails generate gem" addition.
--
Jack Kinsella
On Dec 8, 5:34 pm, "James B. Byrne" <byrn...@harte-lyne.ca> wrote:
> On Wed, December 8, 2010 11:31, Ernie Miller wrote:
> > On Dec 8, 2010, at 11:22 AM, Kevin Skoglund wrote:
> >> 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'.
>
> --
> *** E-Mail is NOT a SECURE channel ***
Ryan Bigg
bundle gem <gemname>
PivotalBoulderMikeG
https://github.com/rails/rails/commits/master/railties/lib/rails/generators/rails/plugin_new
On Dec 10, 1:34 pm, Ryan Bigg <radarliste...@gmail.com> wrote:
> Bundler comes with a gem generator:
>
> bundle gem <gemname>
>
Piotr Sarnacki
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
On Dec 14, 6:37 am, PivotalBoulderMikeG <mgehard
> https://github.com/rails/rails/commits/master/railties/lib/rails/gene...