I wanted to get the conversation started...what do people think? http://pivotallabs.com/users/mgehard/blog/articles/1499 -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> 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. -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Dec 7, 3:34 pm, Michael Koziarski <mich...@koziarski.com> wrote:> 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 -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On 07-12-2010 18:34, Michael Koziarski wrote:>> 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 presentOn 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 -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Wed, Dec 8, 2010 at 7:50 AM, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com>wrote:> On 07-12-2010 18:34, Michael Koziarski wrote: > >> 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> > 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > >-- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Or even easier: # Gemfile gemspec Yehuda Katz Architect | Strobe (ph) 718.877.1325 On Tue, Dec 7, 2010 at 5:56 PM, Jan <jan.h.xie@gmail.com> wrote:> > > On Wed, Dec 8, 2010 at 7:50 AM, Rodrigo Rosenfeld Rosas < > rr.rosas@gmail.com> wrote: > >> On 07-12-2010 18:34, Michael Koziarski wrote: >> >>> 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 > > >> >> 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 rubyonrails-core@googlegroups.com. >> To unsubscribe from this group, send email to >> rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/rubyonrails-core?hl=en. >> >> > -- > 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. >-- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> 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.> > 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. > >-- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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. On Dec 7, 7:00 pm, Michael Koziarski <mich...@koziarski.com> wrote:> > 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. > > > > > 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 rubyonrails-core@googlegroups.com. > > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > > For more options, visit this group athttp://groups.google.com/group/rubyonrails-core?hl=en. > > -- > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Tue, Dec 7, 2010 at 10:00 PM, Michael Koziarski <michael@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 -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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 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"'')? Em 08-12-2010 00:14, Yehuda Katz escreveu:> Or even easier: > > # Gemfile > gemspec > > Yehuda Katz > Architect | Strobe > (ph) 718.877.1325 > > > On Tue, Dec 7, 2010 at 5:56 PM, Jan <jan.h.xie@gmail.com > <mailto:jan.h.xie@gmail.com>> wrote: > > > > On Wed, Dec 8, 2010 at 7:50 AM, Rodrigo Rosenfeld Rosas > <rr.rosas@gmail.com <mailto:rr.rosas@gmail.com>> wrote: > > On 07-12-2010 18:34, Michael Koziarski wrote: > > 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 > > > 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 > rubyonrails-core@googlegroups.com > <mailto:rubyonrails-core@googlegroups.com>. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com > <mailto:rubyonrails-core%2Bunsubscribe@googlegroups.com>. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > > > -- > 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 > rubyonrails-core@googlegroups.com > <mailto:rubyonrails-core@googlegroups.com>. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com > <mailto:rubyonrails-core%2Bunsubscribe@googlegroups.com>. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > > > -- > 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en.-- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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. -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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. On Dec 8, 7:17 am, Daniel Morrison <dan...@collectiveidea.com> wrote:> 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.-- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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. -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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. -- Ernie Miller http://metautonomo.us http://github.com/ernie http://twitter.com/erniemiller -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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:ByrneJB@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 -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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. -- 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 *** > James B. Byrne mailto:Byrn...@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-- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Bundler comes with a gem generator: bundle gem <gemname> On 10/12/2010, at 22:49, Jack Kinsella <jack.kinsella@gmail.com> wrote:> 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. > > -- > 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 *** >> James B. Byrne mailto:Byrn...@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 > > -- > 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. >-- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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 On Dec 10, 1:34 pm, Ryan Bigg <radarliste...@gmail.com> wrote:> Bundler comes with a gem generator: > > bundle gem <gemname> > > On 10/12/2010, at 22:49, Jack Kinsella <jack.kinse...@gmail.com> wrote: > > > > > > > > > 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. > > > -- > > 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 *** > >> James B. Byrne mailto:Byrn...@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 > > > -- > > 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 rubyonrails-core@googlegroups.com. > > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > > For more options, visit this group athttp://groups.google.com/group/rubyonrails-core?hl=en.-- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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 On Dec 14, 6:37 am, PivotalBoulderMikeG <mgehard +goo...@pivotallabs.com> wrote:> Looks like someone has started to move down the gem route... > > https://github.com/rails/rails/commits/master/railties/lib/rails/gene... > > On Dec 10, 1:34 pm, Ryan Bigg <radarliste...@gmail.com> wrote: > > > > > > > > > Bundler comes with a gem generator: > > > bundle gem <gemname> > > > On 10/12/2010, at 22:49, Jack Kinsella <jack.kinse...@gmail.com> wrote: > > > > 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. > > > > -- > > > 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 *** > > >> James B. Byrne mailto:Byrn...@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 > > > > -- > > > 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 rubyonrails-core@googlegroups.com. > > > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > > > For more options, visit this group athttp://groups.google.com/group/rubyonrails-core?hl=en.-- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.