I have a simple rails install generator for an engine I'm making:
module Bouncer
module Generators
class InstallGenerator < Rails::Generators::Base
source_root File.expand_path("../../templates", __FILE__)
desc "Copies locale file and migrations to your application."
def copy_locale
copy_file "../../../config/locales/en.yml", "config/locales/bouncer.en.yml"
end
def copy_migrations
# I would like to run "rake bouncer_engine:install:migrations" right here
# rather than copy_file "../../../db/migrate/blah.rb", "db/migrate/blah.rb"
end
end
end
end
When a user runs rails g bouncer:install, a locale file is copied into their app. I also want to copy in my migrations, but rather than use copy_file method, I was hoping I could just run rake bouncer_engine:install:migrations inside the generator, like I would do from the command line. How can I do this?
The correct way to do this:
#!/usr/bin/env rake
module Bouncer
module Generators
class InstallGenerator < Rails::Generators::Base
desc "Copies migrations to your application."
def copy_migrations
rake("bouncer_engine:install:migrations")
end
end
end
end
This saves a lot of hassle and even takes care of the making sure each migration's name is timestamped properly.
Well, I think it should be possible by just executing the shell command. Here are 6 different ways to execute a shell command in ruby.
But my other suggestion would be instead of implementing it as a rake task, to direcly implement it as part of your generator... I don't know what your exact demands are, but given your description it seems to me that the migrations-task only runs once, when you execute the install task? Or is there a special need to offer it as a rake task as well?
Related
I followed this tutorial to create a rails plugin.
Section 3 explains how to add a method to string that is available anywhere in a Rails application. Now for my case, I want to be able to access rails methods in the plugin itself.
For example in lib/plugin/my_plugin/my_plugin.rb I want to use:
Rails.application.eager_load!
But every time running the gem with an executable it throws following error:
undefined method `eager_load!' for nil:NilClass (NoMethodError)
Now I know this error is thrown because there's no Rails application, but I added the plugin to a Rails application and it also doesn't seem to work (same error) and can't find another way to get this working. Am I approaching this problem the wrong way or is there even a better way?
lib/plugin/my_plugin/my_plugin.rb:
require 'rails'
class MyPlugin
def fetch_models
arr_models = []
Rails.application.eager_load!
::ApplicationRecord.descendants.each do |model|
arr_models[] << model
end
end
end
Steps reproduce:
Create a new plugin rails plugin new custom
Add lib/custom/generator.rb
lib/custom/generator.rb:
require 'faker'
require 'rails'
class Generator
def fetch_models
arr_models = []
Rails.application.eager_load!
ApplicationRecord.descendants.each do |model|
arr_models[] << model
end
end
end
Edit lib/custom.rb
lib/custom.rb:
require "custom/generator"
require "custom/version"
require "custom/railtie"
module Custom
def self.generate
generator = Generator.new
models = generator.fetch_models
end
end
Add executable in bin/
bin/custom:
#!/usr/bin/env ruby
require 'custom'
Custom.generate
Edit custom.gemspec so that bin/test passes
Execute following commands:
$ bundle exec rake build
$ bundle exec rake install
Plugins usually are built to extend core classes.
Using the generator and following the linked guide at my_plugin/lib/my_plugin/rails_core_ext.rb you have to use class you want to extend.
Your code become
class RailsPlayground::Application
def fetch_models
arr_models = []
Rails.application.eager_load!
ApplicationRecord.descendants.each do |model|
arr_models[] << model
end
end
end
or
class RailsPlayground::Application
def fetch_models
Rails.application.eager_load!
ApplicationRecord.descendants
end
end
rails g task folder1/namespace1 task1
Above command will create the task1.rake inside lib/tasks/task1.rake
But, I need to keep my task1.rake inside lib/tasks/folder1/task1.rake
The rails g task generator does not work this way.
Here are the code for the TaskGenerator class
module Rails
module Generators
class TaskGenerator < NamedBase # :nodoc:
argument :actions, type: :array, default: [], banner: "action action"
def create_task_files
template 'task.rb', File.join('lib/tasks', "#{file_name}.rake")
end
end
end
end
As you see the lib/tasks path is hardcoded and you can not pass in options to alter the path.
I think this might be a great addition to the TaskGenerator class.
The answer to your question is that you have to make the folders manually.
I'm building a Rails engine in a ruby gem. It includes some migrations right now that are called when you run:
rails g myengine:install
The code in the generator is as follows:
module MyEngine
module Generators
class InstallGenerator < ::Rails::Generators::Base
include Rails::Generators::Migration
source_root File.expand_path('../templates', __FILE__)
# ...
def copy_migrations
migration_template "migrations/migration1.rb", "db/migrate/migration1.rb"
migration_template "migrations/migration2.rb", "db/migrate/migration2.rb"
end
# ...
end
end
end
However, if I run rails g myengine:install again, it fails with this error:
Another migration is already named migration1: /Users/jh/Code/Web/demoapp/db/migrate/20130327222221_migration1.rb
I want it to just silently ignore the fact that there's already a migration and continue on to the next migration. What would be the best way to do this?
EDIT:
Per Dmitry's answer, this was my solution:
def copy_migrations
copy_migration "migration1"
copy_migration "migration2"
end
protected
def copy_migration(filename)
if self.class.migration_exists?("db/migrate", "#{filename}")
say_status("skipped", "Migration #{filename}.rb already exists")
else
migration_template "migrations/#{filename}.rb", "db/migrate/#{filename}.rb"
end
end
Using migration_template in Rails as example, you could perhaps check for destination = self.class.migration_exists?(migration_dir, #migration_file_name) and if migration already exists, skip over making migration_template call.
I'm writing a Rails 3.1 engine and testing with RSpec 2. When I use rails generate, I get spec files generated for me automatically, which is so convenient:
$ rails g model Foo
invoke active_record
create db/migrate/20111102042931_create_myengine_foos.rb
create app/models/myengine/foo.rb
invoke rspec
create spec/models/myengine/foo_spec.rb
However, to make the generated specs play nicely with my isolated namespace, I have to wrap the spec each time manually in a module:
require 'spec_helper'
module MyEngine
describe Foo do
it "should be round"
...
end
end
I would love to know if there's a clean and easy way to modify the automatically generated spec 'templates' so that I don't have to wrap the spec in Module MyEngine each time I generate a new model or controller.
You can copy RSpec's templates using a Rake task like:
namespace :spec do
namespace :templates do
# desc "Copy all the templates from rspec to the application directory for customization. Already existing local copies will be overwritten"
task :copy do
generators_lib = File.join(Gem.loaded_specs["rspec-rails"].full_gem_path, "lib/generators")
project_templates = "#{Rails.root}/lib/templates"
default_templates = { "rspec" => %w{controller helper integration mailer model observer scaffold view} }
default_templates.each do |type, names|
local_template_type_dir = File.join(project_templates, type)
FileUtils.mkdir_p local_template_type_dir
names.each do |name|
dst_name = File.join(local_template_type_dir, name)
src_name = File.join(generators_lib, type, name, "templates")
FileUtils.cp_r src_name, dst_name
end
end
end
end
end
Then you can modify the code in #{Rails.root}/lib/templates/rspec/model/model_spec.rb to include the module name.
Copy the '/lib/generators/rspec/scaffold/templates/controller_spec.rb' file from the rspec-rails gem to your 'app/lib/templates/rspec/scaffold' folder, then customize it. Obviously, if you move to a new version of rspec-rails you will want to make sure that your customized template hasn't gotten stale.
I have a number of parsers I run with rakes in a project I'm working on. When using a method name that already exists in another rake, and because they both use the same environment, I get a conflict.
Is there a way to limit the scope of rake files within their namespace? I thought that was the whole point of the namespace?
Example:
namespace :test do
task :test_task => :environment do
...
end
def test_method(argument)
...
end
end
namespace :other_test do
task :test_task => :environment do
...
end
def test_method(argument, argument2)
...
end
end
In this case, when running rake test:test_task I'll receive an invalid amount of arguments error. On the other hand, if I define the method within the task itself, I have to keep the method at the top of the rake file in order. This gets kind of confusing and ugly.
Is that just a necessary evil?
Thanks!
I see the namespaces for rake tasks as serving the same purpose as directories in a file system: they're about organization rather than encapsulation. That's why database tasks are in db:, Rails tasks in rails:, etc.
Rake namespaces are not classes so you need to ask yourself what class you're adding test_method to when you define it within a Rake namespace. The answer is Object. So, when you hit your second task, Object already has a test_method method that takes one parameter and Ruby rightly complains.
The best solution is to make your Rake tasks very thin (just like controllers) and put any supporting methods (such as test_method) off in some library file somewhere sensible. A Rake task should usually just do a bit of set up and then call a library method to do the real work (i.e. the same general layout as a controller).
Executive summary: put all the real work and heavy lifting somewhere in your library files and make your Rake tasks thin wrappers for your libraries. This should make your problem go away through proper code organization.
module Anonymous
namespace :test do
# brabra
end
end
self.class.send(:remove_const, :Anonymous)
module Anonymous
namespace :another_test do
# brabra
end
end
self.class.send(:remove_const, :Anonymous)
Module.new do end block needs you self:: before any definition. To avoid this, you need to name the module and remove it.
I've figured out a way to namespace the methods in Rake tasks so same-named methods don't collide.
Wrap each outer namespace in a uniquely-named module.
extend Rake::DSL
Change your methods to class methods (with self.).
I've tested this, and it still allows one rake task to invoke or depend on another rake task that is in a different module.
Example:
module Test
extend Rake::DSL
namespace :test do
task :test_task => :environment do
...
end
def self.test_method(argument)
...
end
end
end
module OtherTest
extend Rake::DSL
namespace :other_test do
task :test_task => :environment do
...
end
def self.test_method(argument, argument2)
...
end
end
end