I have the puma gem in my Rails 4.1.8 Gemfile because I want to use it as the default webserver in all environments. That works fine.
# Gemfile
gem "puma"
In development I am using mailcatcher which means that I'd like to include it as a dependency in my Gemfile.
# Gemfile
group :development do
gem "mailcatcher"
end
This causes the default webserver to be set to thin. This appears to be an unintended consequence of mailcatcher, but it brings up a specific question. Can I create a group that bundler obeys to install Gems, but that Rails ignores? I tried something like this but Rails is still loading the contained gems.
# Gemfile
group :mailcatcher do
gem "mailcatcher"
end
You can alias rails s command... For example export alias rs="rails server puma" and now rs will start puma. This way you are free to use any webserver you want )
If you want to make it really default you can add something like this
require 'rack/handler'
Rack::Handler::WEBrick = Rack::Handler.get(:puma)
to the rails script.
I don't know if this will work or not, but what about:
gem "mailcatcher", :require => false
Ref: Bundler: What does :require => false in a Gemfile mean?
Mailcatcher specifically states to not put it in your Gemfile.
Please don't put mailcatcher into your Gemfile. It will conflict with your applications gems at some point.
Instead, pop a note in your README stating you use mailcatcher. Simply run gem install mailcatcher then mailcatcher to get started.
Related
I am getting the error when starting the server rails s in my local environment.
I tried to google , but all these capistrano Dont know how to build tasks are all deploy related, not when starting server in local environment.
I am not sure either whether its a rails or capistrano issue.
Here is the link of the trace. Gist.
Any help is appreciated!
application.rb
You probably have Capistrano-related gems in your Gemfile but have not marked them as require: false. As a result, when Rails boots up, it tries to load all of that Capistrano code, which is not how Capistrano is intended to be used.
In your case it looks like the capistrano-gitflow gem is the culprit. Always use require: false for it and all other Capistrano-related gems in the Gemfile, like this:
gem "capistrano", "~> 3.10", require: false
gem "capistrano-bundler", require: false
gem "capistrano-rails", require: false
The fact that this is not explained in the Capistrano documentation is an oversight that I will try to get corrected.
I want to use awesome print without putting it in my rails 5 app. Just in the console. The documentation for requiring it in irb is not working.
That's because bundler isolates the gems available to load to what's in your Gemfile.
The best way to get around this is to add the gem to your Gemfile
gem 'awesome_print', require: false, group: :development
And in your .irbrc, you can require it, so that it is only enabled for you:
begin
require 'awesome_print'
rescue LoadError => err
warn "could not require awesome_print: #{err}"
end
However, if you aren't permitted to add awesome_print to your repository for whatever reason, there are a few hacks to get gems installed, but not in your Gemfile to load in this GitHub Gist.
One such example that could be placed at the top of your .irbrc:
# Add all gems in the global gemset to the $LOAD_PATH so they can be used even
# in places like 'rails console'.
if defined?(::Bundler)
global_gemset = ENV['GEM_PATH'].split(':').grep(/ruby.*#global/).first
$LOAD_PATH.concat(Dir.glob("#{global_gemset}/gems/*/lib")) if
global_gemset
end
cd your/rails/project
irb
inside irb, run:
require 'awesome_print'
require './config/environment'
and you have both rails console and awesome_print gem while the gem is installed outside of the bundler.
I have Rails 3.0.x application. I would like to load gems on runtime, without using Gemfile.
What I would like to accomplish is to load my application as usual, with regular gems being loaded by Bundler. After that I would like to load all gems (Rails Engines) located in a specific directory (but until runtime, I don't know what gems will that be).
Does anybody know if this is possible in Rails, maybe using Bundler API?
What you're trying to do is dangerous. If each of your Rails Engines are also gems - then they would also have Gemfiles with other dependencies, and those would in turn have other dependencies, etc. If you allow Bundler to resolve those, then you would have lesser problems at runtime.
Here's how you would do it without any hacks. Remember that your Gemfile is just Ruby code, and you can have gems which are not loaded by default.
# In your Gemfile, add at the end:
Dir[YOUR_RAILS_ENGINES_SUBFOLDER + "/*/*.gemspec"].each do |gemspec_file|
dir_name = File.dirname(gemspec_file)
gem_name = File.basename(gemspec_file, File.extname(gemspec_file))
# sometimes "-" and "_" are used interchangeably in gems
# for e.g. gemspec_file is "engines/my-engine/my_engine.gemspec"
# dir_name will be engines/my-engine
# gem_name will be my_engine
# Register that engine as a dependency, *without* being required
gem gem_name, :path => dir_name, :require => false
# e.g. this is similar to saying
# gem 'my_engine', :path => 'engines/my-engine', :require => false
end
Now you have all your dynamic Rails engines registered as gem dependencies. Bundler will resolve them, and all their sub-dependencies, so you don't have to worry about anything. Just run bundle install once before running the application, or whenever you add/remove any engine in that folder.
The good thing is, these gems will just be registered, and not loaded. So in your production code, you can now load whatever gem that you choose at runtime simply by saying require <your-engine-name>
Edit: Extra code comments
Try this:
Bundler.with_clean_env do
# require gems...
end
With a new Rails 2.3.10 project, the file config/environment.rb has the following line commented out:
# config.gem "sqlite3-ruby", :lib => "sqlite3"
but for some reason, I tried a scaffold foo, and start the rails server, and the app is running.
I thought the requirement is, every gem the app needs, it has to be listed in config/environment.rb?
In Rails 2.3, it's enough to have the gem installed on your system for you to use it.
In Rails 3, you must have the gem listed in your Gemfile and installed via bundler to use the gem.
I've been told that doing:
config.gem 'tzinfo'
doesn't obviate the need to require 'tzinfo'. Is this true of all gems? If yes, what exactly does adding config.gem WHATEVER do?
config.gem should cause the gem to be automatically required. You should not need to do a manual 'require' call.
config.gem
Tells Rails to load this gem automatically
Tells Rails that this gem is needed for the application, so that rake gems:install will install it
The :source option can tell rails to get it from a nonstandard repository
The :lib option can tell rails to load a non-standard file from the gem (i.e. something not named after the gem itself)
If i'm correct, during the environment initialization 'config.gem' allows your app to setup and require GEM dependencies from within the app, without the need to have to install them manually. (As we did before) By calling "config.gem tzinfo" as you did above, it automagically requires the gem across the app. This helps when you deploy to an external server and need to prepare the app along with necessary gems, etc. You can then run RAKE GEMS:INSTALL and rails will pull in all your gems and require them.
A thing to note though is that if you DO NOT want a gem to be required across your app. Then add ":lib => false" after config.gem i.e (config.gem 'tzinfo' :lib => false).
In some cases, (I followed your link) if you're getting an uninitialized gem, and you've manually installed it. Make sure that the config.gem ":lib" directory matches with the correct :lib directory of the gem. I.E a gem may be packaged and installed as "nlewis-supergem", however I may need to point the lib at "supergem". i.e "config.gem "nlewis-supergem" :lib=>"supergem". It all depends on how some people package their gem and the corresponding libraries.
A quick tip is instead of installing manually always install the gem via "config.gem" and then rake GEMS:INSTALL to catch any wierd errors before deployment.
Hope this helps.