April 5th, 2015
(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: firstname.lastname@example.org
Sometimes Google disappoints. If you search for “gem plugins railtie” the first link is to an article that is 5 years old. Is there truly no better information? That article says:
Railtie plugins are easy to turn into gem plugins for Rails. This makes them easy to distribute, manage, and upgrade. The first thing you need is a gem. If you don’t have a gem yet, you can create a new gem easily using Bundler. Just run bundle gem my_new_gem and Bundler will generate a skeleton gem and gemspec that follow gem best practices. Once you have a gem, just make sure that your Railtie subclass is defined when lib/my_new_gem.rb is loaded. You can define the Railtie in a separate file and require that file, or define it directly. Last, add a dependency on the Rails gem (~>3.0) to your gemspec.
If your gem is also a plain Ruby library, and you don’t want to depend on the Rails gem, then you can put your Railtie in a separate file, and conditionally require that file inside your main library file.
class MyCoolRailtie < ::Rails::Railtie
# Railtie code here
require ‘my_new_gem/my_cool_railtie.rb’ if defined?(Rails)
This ensures that your gem can be loaded (without the Railtie) if it is loaded outside the context of a Rails application.
Plugins are an alias for Gems. However, there is another layer to this discussion. Prior to Rails 3.2 and officialy in Rails 4 there were things were officially called “plugins.” Plugins were usually smaller than Gems and lived inside vendor/plugins. Essentially no one uses them anymore besides Heroku because they love raising deprecation errors in current applications. You can use rails plugin new which will generate a new gem that’s connected to rails via railties.
The name itself defines its purpose. A “railtie” provides a connector for external code to tie into Rails. It allows you do things like define configuration for Rails or add initializers. Here are some common use cases suggested from the Railtie docs:
configuring a Rails framework for the application, like setting a generator
adding config.* keys to the environment
setting up a subscriber with ActiveSupport::Notifications
adding rake tasks
ActiveRecord, ActionPack, ActiveSupport are all connected to rails via railties. Railties connect separate sections of code into Rails. Here is an real life example of a simple Railtie in the wild:
class Railtie < ::Rails::Railtie
config.cashier = Cashier
ActiveSupport::Cache::Store.instrument = true
Connecting non rails code to rails
"Engines" are actually a railtie subclass. They can do everything a railtie can do and more. Engines are essentially self contained rails applications. They can have all their own models, controllers, views, routes, and internal code. Engines can be packaged as gems. You can do everything in an engine that you can do in your application. That's because your Rails application is actually just an engine. You can generate a new engine like this: rails plugin new foo --mountable (Yes plugin is confusing.)
You want make a self contained rails application that can be redistruted.
You want to decompose your large rails application into smaller components
The joke about plugins is useful.Source