I'm attempting to create a new Rails 3 plugin gem which wraps around devise/devise_ldap_authenticatable for reusable drop in internal LDAP support.
I create the new plugin gem with:
rails plugin new <gem_name>
I then add the devise/devise_ldap_authenticatable gems to the .gemspec file and run bundle
In the devise instructions it says to generate the required files using its generators:
rails generate devise:install
rails generate devise MODEL
However, in the directory where the plugin is generated I don't seem to be able to run rails generate. Most gem plugin tutorials instruct you to just create the files manually. Am I better off starting a new rails project, following the instructions in the temp project, then copying the files over to the plugin manually? Is there something that I'm missing? Can I run the generator script from the dummy instance? What is the standard practice in this use case?
In the end, I opted to forgo wrapping devise_ldap_authenticatable due to its relative simplicity.
The answer that I would go with in the future is to just to move files from a throwaway project.
Related
I am trying to learn ruby on rails. I created a new project with Rails 6.1.2.1 for this purpose but it took more than 5 minutes. The problem is after creating the project, it creates a huge 100Mb+ dir which is called node_modules with every possible node_package. This does not make sense as the default behavior. Am I actually missing something?
The node_modules are for your front-end stuff. Now Ruby on Rails supports webpacker with all goodies of NodeJS. It is already in .gitignore and it is normal behavior.
When you want to save your project, you can delete this folder and whenever you need you can use yarn install to get it back.
You can create rails app without installing webpacker
--skip-webpack-install option of Rails new. It still includes the webpackergem in the Gemfile and sets up the resulting project with webpacker configuration (only rails webpacker:install is not run).
I'm trying to introduce the Vanity gem into a project and everything is happy right up until I try to run the generator. This is the call:
rails generate vanity
And this is the output:
Could not find generator 'vanity'. Maybe you meant 'vanity', 'task' or
'mailer'
Run rails generate --help for more options.
Notice that it can't find 'vanity' and then suggests vanity. Wut? I then took a moment to verify that the generator actually exists:
rails generate --help | grep "anity"
and got:
Vanity:
vanity
vanity:views
I am using Spring, so I stopped that with spring stop.
I should also note that I tried a bunch of things like:
rails generate Vanity:vanity
rails generate vanity:vanity
rails generate Vanity
rails generate oh:please:do:vanity
Additionally, I am actually using bundler so I tried ALL these things with and without bundle exec at the beginning of the commands.
I wonder if perhaps this error is actually masking an issue in my local setup, but I've looked really closely and am convinced that the installation and setup of vanity is correct.
Version information:
ruby 2.5.5p157
Rails 5.2.3
Vanity 3.0.0
EDIT: additional information: I went down the path of stopping the Spring server, bundle update and then trying the generator--nothing changed. I've even tried going into the actual generator and debugging there. While it loads the file, it never executes any of the methods.
Solved this on my own. It turns out that the vanity gem wasn't automatically pulling the generators into the load path. That means that when the generator was called, it was erroring out because it couldn't find the actual generator class in the first place.
The generator error was masking that error and making it look like the generator itself couldn't be found.
The fix for this was to explicitly require the generators in a config/initializers/vanity.rb file.
The vanity gem claims that in Rails apps the classes are "automagically" available.
What is the difference between Gem package, plugin, and Engine in Ruby on Rails?
I think we use the plugin before Rails3.2 and after rails3.2 is released we are using the gem package as a plugin but how can we use the engine in ROR?
Plugins as you knew them from Rails 2 (i.e. plugins under the vendor/plugins folder) were deprecated for Rails 3.2; support for it was completely removed in Rails 4. Now, there's a concept of a "gamified plugin" where the plugins are essentially built as gems and can be shared across different Rails applications.
But to answer your question about gems vs plugins, check out this Stackoverflow answer. Long story short, plugins from the Rails 2 universe is an extension of the rails application, whereas a gem is a packaged ruby application.
As for Rails engines, I've found this to be a pretty easy and intuitive definition of a Rails engine:
Rails Engines is basically a whole Rails app that lives in the container of another one. Put another way, as the docs note: an app itself is basically just an engine at the root level. Over the years, we’ve seen sen engines as parts of gems such as devise or rails_admin. These examples show the power of engines by providing a large set of relatively self-contained functionality “mounted” into an app.
And since both rails engines and plugins are types of ruby applications, they can all technically be packaged and used as a gem (usually).
There are no more plugins since Rails 4. Rails 4.0 release notes:
Rails::Plugin has gone. Instead of adding plugins to vendor/plugins
use gems or bundlers with path or git dependencies.
Any engine can be contained in a gem. Gem is just an alias to a 'library'.
Best way to see what their difference is is by generating three of them and looking through their directory structure:
bundle gem a_gem, used for non-rails-specific functionality.
rails plugin new b_railtie, used for rails extensions that don't require a full application-like setup. but, since it's still a rails-specific setup (you get your Rails dummy app in /test eg), you are probably going to use railtie in it. railtie is a class that inherits from Rails::Railtie, and gives you the comfortable DSL to hook up your code into Rails. eg, if you want some action performed :before some Rails app initialization step, you can use initializer Railtie class_method. Paperclip
rails plugin new c_engine --full, use for rails extensions that will be full-fledged app themselves, mounted into your app. will give you /app dir and Engine subclass besides basic non---full setup.
rails plugin new c_engine --mountable, same as --full, but will create namespaces, ready to be mounted into your app engine. Spree
And here is a pretty good link: http://hawkins.io/2012/03/defining_plugins_gems_railties_and_engines.
Engines are very related to plugins. Engines can be plugins and plugins can be engines. All of them can be created using rails plugin generator with 2 different options --full or --mountable.
I think the main difference here is between Engines and Gems.
Gems is just a bit of code providing a set of functionalities to anyone who integrates it into its code.
It contains:
Gemspec
Lib folder
Can be packaged and pushed to RubyGems servers
Engines are actually gems. All engines can be gems (if packaged) but not all gems are engines.
We can say it with a different word, Engines is a Ruby on Rails feature, that can contain Rails-specific entities: models, controllers, views, and migrations.
It needs to be integrated inside Rails application and can't run on its own.
Very good and quick read Artricle
I've spent a few hours trying to figure out how to install a plugin in Rails 3 (probably the time it wouldve taken me to build the plugin myself). So rather than wasting more time,I'm hoping someone can simply explain how I can incorporate plugins in the vendor/plugins folder (which I've unzipped there) into an application. The installation instructions for Rails 2 are below:
Then you need to copy the configuration files, database migration and UI files into your application like so:
./script/generate install_has_threaded_comments
Rails 3.2 has deprecation warnings for using vendor/plugins and advocates adding gems to your Gemfile for everything.
gem 'acts_as_commentable_with_threading'
Rails 3 converts Rails 2's script/generate (or script/anything) to:
rails generate acts_as_commentable_with_threading_migration
Typically I create a plugin when I have a module that I know I'm going to need over again in my other projects, however, they could also be packaged as gems.
When should I be building a gem over creating a plugin? Is there any criteria for making the call?
Plugins are becoming obsolete now that you can manage gems via the "config.gem" statement in environment.rb. Gems are available system-wide (not just in one app), and are versioned unlike plugins.
I've converted all of my plugins to gems recently. Easy to do and well worth it.
Rails seems to be moving towards the gem direction. I have converted most of my plugins to gems now. Gems are easier to manage and fit better in the Ruby eco-system. Why do we need two separate systems anyway?
There is still a problem with gems however: it is not possible to add rake tasks to a Rails application from a gem. Probably the same holds for generators, although I'm not sure. If you use these in your plugin, migrating to a gem is not yet possible. Hopefully this gets fixed soon.
you can add generators to rails via gems. it's actually pretty easy, you can just add a rails_generators directory to your gem. (i think other directory names will work - i'm not sure what rails searches for). example: http://github.com/remi/rackbox/tree/a21c21667c68d5fd51357e28f0742171e9161e9b/rails_generators
as for adding rake tasks ... i have yet to figure out howto do that :/
for now, i'm having my generators add require 'myproject/rails/tasks' (or something) to the project's Rakefile as a way to add rake tasks to rails from a gem.
a lot of gems ask you to 'bootstrap' them into your rails project, eg.
sudo gem install cucumber
cd rails_app
./script/generate cucumber # bootstrap cucumber into your app