Related to this questions, I have a gem that uses rails 4.1.8 and rspec 2.99. When I run my rspec suite I get the deprecation notice:
[deprecated] I18n.enforce_available_locales will default to true in the future. If you really want to skip validation of your locale you can set I18n.enforce_available_locales = false to avoid this message.
In the linked post, the solution was to add config.i18n.enforce_available_locales = true to the application.rb; however, there is no such file for gem and I don't know where to set configuration settings for a gem.
Update
I tried adding this statement into my railtie.rb as that seemed to be implied in the Railtie documentation, but that doesn't seem to have any effect.
Related
I'm a bit late with Rails version upgrade. What surprised me was a bunch of active_support requires in config/environment/* files generated by Rails.
What are they for? Does it have something to do with Zeitwerk that was introduced in Rails6?
I don't remember them being present in older versions of Rails.
ag ^require config/environments
config/environments/development.rb
1:require "active_support/core_ext/integer/time"
config/environments/test.rb
1:require "active_support/core_ext/integer/time"
config/environments/production.rb
1:require "active_support/core_ext/integer/time"
Steps to reproduce:
rails new myapp
cat Gemfile | grep "^gem 'rails'"
gem 'rails', '~> 6.1.3', '>= 6.1.3.2'
I tried to find this update in rails/rails CHANGELOG and some git blaiming but that didn't help.
A little bit further down each environment file, the code that the require statement loads is used (or is referenced in comments, in the case of the production file). From the default development.rb:
# Enable/disable caching. By default caching is disabled.
# Run rails dev:cache to toggle caching.
if Rails.root.join('tmp/caching-dev.txt').exist?
config.cache_store = :memory_store
config.public_file_server.headers = {
'Cache-Control' => "public, max-age=#{2.days.to_i}" # <- NOTE THIS LINE
}
else
config.action_controller.perform_caching = false
config.cache_store = :null_store
end
That require statement adds support for expressions like 2.days.to_i - core_ext/integer/time loads some functions, but also requires core_ext/numeric/time.
So the require statement is being a good Ruby citizen, and making sure that the particular part of Rails that its code relies upon is guaranteed to be loaded in order to be able to parse that line correctly.
I don't know why it wasn't needed before (it could be a Zeitwerk-related issue, as you suggest, that's a part of Rails 6+ I'm not too familiar with yet).
But at the end of the day, if the whole Rails stack is loaded before this file is evaluated, the require won't have any additional effect – and if it's not, this file will load what it needs and then the rest of Rails will load as needed.
I've been struggling to deploy an application in production with config.eager_load = true.
I know this configuration loads most of Rails and application code in memory, and it's a nice feature to have in production(like) environments, the problem is that i have a custom rails engine with some code that is used only on certain modules of my main application code and it's only required on certain files.
My custom engine is installed like this in Gemfile:
gem 'gem_name', require: false
and required in files like this:
require 'gem_name'
So, when i run rails s -e production (which has config.eager_load=true activated) it fails automatically with the following error
bootsnap/load_path_cache/core_ext/kernel_require.rb:58:in `load': No
such file to load (LoadError)
Any ideas on how to make eager_load work when a gem is not required on Gemfile?
gem 'gem_name', require: false
And what problems could i have if i set eager_load to false on production(like) environments?
I researched for a bit, try upating bootsnap gem, try delete 'bootsnap-load-path-cache' and 'bootsnap-compile-cache' from tmp/cache folder.
This article May help understand eager load https://blog.arkency.com/2014/11/dont-forget-about-eager-load-when-extending-autoload/
This topic may help understand
What's the impact of eager_load=true?
it points to other solution, not require but autoload(http://www.rubyinside.com/ruby-techniques-revealed-autoload-1652.html)
From the guides(please read):
https://guides.rubyonrails.org/autoloading_and_reloading_constants.html#autoload-paths-and-eager-load-paths
For those that need to autoload all files inside a directory instead of requiring them, you can do this:
Dir.glob(File.join(some_path, 'lib', 'extensions', '*.rb')).map do |file|
autoload File.basename(file).gsub('.rb', '').classify.to_sym, file
end
instead of the classic
Dir[File.join(some_path, 'lib', 'extensions', '*.rb')].each do |f|
require f
end
You placed something like this in config/application.rb
I18n.enforce_available_locales = true
config.i18n.load_path += Dir[Rails.root.join('config/locales/', '*.{rb,yml}').to_s]
config.i18n.available_locales = ['es-LA', :en]
config.i18n.default_locale = 'es-LA'
And the warning still appears:
[deprecated] I18n.enforce_available_locales will default to true in the future.
The reason is due to a bug with locales that have the language-country format. The good news is that it has been fixed already. This was reported in Github with Issue 13164 and fixed with pull request 229.
If you want to grab the latest code with the fix, update the gem like this:
Update your Gemfile with:
gem 'i18n', github: 'svenfuchs/i18n'
And then: bundle install
I'm looking for a way to suppress Ruby warnings when I run my specs.
spec spec/models/account_spec.rb
I receive warnings such as:
DEPRECATION WARNING: ActiveSupport::Dependencies.load_paths is deprecated, ...
warning: already initialized constant SOME_CONSTANT_NAME
Removing the ActiveSupport warning is quite easy with ActiveSupport::Deprecation.silenced = true.
How do I prevent the already initialized constant warnings as part of my spec command? Or through creating another spec file that can suppress such warnings. Keep in mind that these warnings are from gem files, therefore I cannot go into those files and surround them with Kernel.silence_warnings.
Note:
I understand that suppressing warnings are bad. However, when I run a single spec from within vim it would be nice if the warnings didn't clutter my screen.
The syntax for RUBYOPT is
RUBYOPT="-W0" rspec
Tested in ruby 2.1.x and 2.14.x
If you run your specs directly with the ruby command instead of the spec wrapper, you can use the -W command line option to silence warnings:
$ ruby --help
[...]
-W[level] set warning level; 0=silence, 1=medium, 2=verbose (default)
So in your case:
$ ruby -W0 -Ispec spec/models/event_spec.rb
should not show you any warnings.
Alternatively, you could set $VERBOSE=nil before your gems are loaded, ie at the top of your environment.rb (or application.rb if you're on Rails 3). Note that this disables all warnings all the time.
Or, since you are using Rails, you should be able to use Kernel.silence_warnings around the Bundler.require block if you're using Bundler:
Kernel.silence_warnings do
Bundler.require(:default, Rails.env) if defined?(Bundler)
end
More selectively, set $VERBOSE only for loading specific gems:
config.gem 'wellbehaving_gem'
original_verbosity = $VERBOSE
$VERBOSE = nil
config.gem 'noisy_gem_a'
$VERBOSE = original_verbosity
Related with this post, you can manage deprecation warnings according to th environment in which you are working, as said in rails guides:
active_support.deprecation_behavior Sets up deprecation reporting for
environments, defaulting to :log for development, :notify for
production and :stderr for test. If a value isn't set for
config.active_support.deprecation then this initializer will prompt
the user to configure this line in the current environment's
config/environments file. Can be set to an array of values.
So just change in config/environments/test.rb the value :stderr for :log
Rails.application.configure do
...
# Print deprecation notices to the log file instead of console.
config.active_support.deprecation = :log
...
end
And with this change, the deprecation warnings will now be printed to the log/test.log instead of the console output.
You can also use the "RUBYOPT" environment variable to pass -W0 to rspec:
RUBYOPT=W0 rspec spec/models/event_spec.rb
This allows you to run multiple specs by passing in a directory
RUBYOPT=W0 rspec spec/models
The only solution that worked for me is to add $VERBOSE = nil on top of my config/environments/test.rb file
Rails.application.configure do
$VERBOSE = nil
I'm with faker warning problems faker-1.9.6/lib/faker/default/number.rb:34.
Use it local because it hides all other warnings.
Putting Warning[:deprecated] = false after require "rails/all" in config/application.rb works very well to suppress those warnings everywhere. You can do
Warning[:deprecated] = false if Rails.env.test?
for your particular case, or better yet - put it in config/environments/test.rb, but I'm not sure how well it is going to work since I belive some stuff is loaded before that.
If you have this in your .rspec file, remove
--warnings
from your .rspec file in your project root.
rspec has a tag option you can use -- I simply used /dev/null.
rspec spec --deprecation-out /dev/null
Actually, perhaps you shouldn't ignore your warnings, but test them, to make sure they are fired where they're supposed to be.
It's not the easiest to use, but it looks like this:
obj.should_receive(:warn).with("Some Message")
I found it here, and tested it for my use case, and it works (and the warnings disappear from the console, of course)
If you're using guard for tests and Rails 6 and you get warnings such as:
- "warning: FILE in eval may not return location in binding"
- "warning: Capturing the given block using Proc.new is deprecated; use &block instead"
- "warning: Using the last argument as keyword parameters is deprecated; maybe ** should be added to the call"
Then the only way so remove them all is to:
Add $VERBOSE = nil to config/environments/test.rb
Run guard with: RUBYOPT='-W0' bundle exec guard
I guess this is not good advice to remove all those warnings so later on, after a few gem updates, we should remove those lines again so that we get the right warnings on your own code usage for example.
Now that Rails 3 beta is out, I thought I'd have a look at rewriting an app I have just started work on in Rails 3 beta, both to get a feel for it and get a bit of a head-start. The app uses MongoDB and MongoMapper for all of its models and therefore has no need for ActiveRecord. In the previous version, I am unloading activerecord in the following way:
config.frameworks -= [ :active_record ] # inside environment.rb
In the latest version this does not work - it just throws an error:
/Library/Ruby/Gems/1.8/gems/railties-3.0.0.beta/lib/rails/configuration.rb:126:in
`frameworks': config.frameworks in no longer supported. See the generated
config/boot.rb for steps on how to limit the frameworks that will be loaded
(RuntimeError)
from *snip*
Of course, I have looked at the boot.rb as it suggested, but as far as I can see, there is no clue here as to how I might go about unloading AR. The reason I need to do this is because not only is it silly to be loading something I don't want, but it is complaining about its inability to make a DB connection even when I try to run a generator for a controller. This is because I've wiped database.yml and replaced it with connection details for MongoDB in order to use this gist for using database.yml for MongoDB connection details. Not sure why it needs to be able to initiate a DB connection at all just to generate a controller anyway....
Is anyone aware of the correct Rails 3 way of doing this?
I'm going by this from reading the source, so let me know if it actually worked. :)
The rails command that generates the application template now has an option -O, which tells it to skip ActiveRecord.
If you don't feel like rerunning rails, you should check the following in your existing app:
Check that your config/application.rb doesn't have require 'rails/all' or require "active_record/railtie". Instead, for a standard Rails setup without ActiveRecord, it should have only the following requires:
require File.expand_path('../boot', __FILE__)
require "action_controller/railtie"
require "action_mailer/railtie"
require "active_resource/railtie"
require "rails/test_unit/railtie"
require "sprockets/railtie"
# Auto-require default libraries and those for the current Rails environment.
Bundler.require :default, Rails.env
If, in config/application.rb, you are using the config.generators section, make sure it doesn't have the line g.orm :active_record. You can set this explicitly to nil, if you want, but this should be the default when g.orm is completely omitted.
Optional, but in your Gemfile, remove the gem line that loads the module for your database. This could be the line gem "mysql" for example.
Rails 4
I was looking for how to disable it in rails 4 and only found this answer which no longer works in rails 4. So this is how you can do it in rails 4 (tested in RC1).
In a new project
rails new YourProject --skip-active-record
In an existing project
In your Gemfile, remove the database driver gem, e.g. gem 'sqlite3' or gem 'pg'.
In config/application.rb, replace require 'rails/all' with
require "action_controller/railtie"
require "action_mailer/railtie"
require "sprockets/railtie"
require "rails/test_unit/railtie"
In config/environments/development.rb, remove or comment out config.active_record.migration_error = :page_load
Potentially you have to remove active_record helpers from the spec_helper (via VenoM in the comments)
Potentially you have to remove the ConnectionManagement middleware (seems to be the case with unicorn): config.app_middleware.delete "ActiveRecord::ConnectionAdapters::ConnectionManagement" (via https://stackoverflow.com/a/18087332/764342)
I hope this helps others looking for how to disable ActiveRecord in Rails 4.
For a new rails app, you can have it exclude active record by specifying the --skip-active-record parameter. Eg:
rails new appname --skip-active-record
If you generated a new project using Rails 3.2, you will also need to comment out:
config.active_record.mass_assignment_sanitizer = :strict
and
config.active_record.auto_explain_threshold_in_seconds = 0.5
in your development.rb file.
All of the above are true. The one more thing which I had to do in rails 3.1 is to comment out
config.active_record.identity_map = true
in config/application.rb.
If you're running rspec, you also need to remove (in spec_helper):
# Remove this line if you're not using ActiveRecord or ActiveRecord fixtures
config.fixture_path = "#{::Rails.root}/spec/fixtures"
and remove
# If you're not using ActiveRecord, or you'd prefer not to run each of your
# examples within a transaction, remove the following line or assign false
# instead of true.
config.use_transactional_fixtures = true
Also comment out
# config/application.rb
config.active_record.whitelist_attributes = true
(noted on rails 3.2.13)