When we have a directory under app/ that we want Zeitwerk to work off of, and say that naming happens to be something like
app/stuff/graphql.rb
app/stuff/graphql_error.rb
then Zeitwerk is looking for some module Stuff that has some module or class Graphql. But in my code, I am always writing my modules and classes as GraphQL to match that convention. So Zeitwerk is now throwing Zeitwerk::NameError as it tries to work with the code. I don't want to use Stuff::GraphqlError, I want to use Stuff::GraphQLError. How do I trick Zeitwerk here?
I believe Zeitwerk has inflectors that can be used for this:
https://github.com/fxn/zeitwerk#inflection
In order for app/stuff to act as a namespace, you have to put app itself as an autoload path. This is a bit tricky, please have a look at https://guides.rubyonrails.org/classic_to_zeitwerk_howto.html#having-app-in-the-autoload-paths.
Rails 6 switched to Zeitwerk as the default autoloader. Zeitwerk will load all files in the /app folder, eliminating the need for namespacing. That means, a TestService service object in app/services/demo/test_service.rb can now be directly called e.g. TestService.new().call.
However, namespacing has been helpful to organize objects in more complex rails apps, e.g. API::UsersController, or for services we use Registration::CreateAccount, Registration::AddDemoData etc.
One solution suggested by the rails guide is to remove the path from the autoloader path in application.rb, e.g. config.autoload_paths -= Dir["#{config.root}/app/services/demo/"]. However, that feels like a monkey patch for shoehorning an old way or organizing objects into the new rails way.
What is the correct way of namespacing objects or a rails 6 way of organizing it without just forcing rails into the old way?
It is not true to say that Zeitwerk eliminates 'the need for namespacing'. Zeitwerk does indeed autoload all the subdirectories of app (except assets, javascripts, and views). Any directories under app are loaded into the 'root' namespace. But, Zeitwerk also 'autovivifies' modules for any directories under those roots. So:
/models/foo.rb => Foo
/services/bar.rb => Bar
/services/registration/add_demo_data.rb => Registration::AddDemoData
If you are already used to loading constants from 'non-standard' directories (by adding to config.autoload_paths), there's usually not much change. There are a couple of cases that do require a bit of tweaking, though. The first is where you are migrating a project that just adds app itself to the autoload path. In classic (pre-Rails 6), this allows you to use app/api/base.rb to contain API::Base, whereas in Zeitwerk it would expect it to contain only Base. That's the case you mention above where the recommendation is to exclude that directory from the autoload path. Another alternative would be to simply add a wrapper directory like app/api/api/base.rb.
The second issue to note is how Zeitwerk infers constants from file names. From the Rails migration guide:
classic mode infers file names from missing constant names
(underscore), whereas zeitwerk mode infers constant names from file
names (camelize). These helpers are not always inverse of each other,
in particular if acronyms are involved. For instance, "FOO".underscore
is "foo", but "foo".camelize is "Foo", not "FOO".
So, /api/api/base.rb actually equates to Api::Base in Zeitwerk, not API::Base.
Zeitwerk includes a rake task to verify autoloading in a project:
% bin/rails zeitwerk:check
Hold on, I am eager loading the application.
expected file app/api/base.rb to define constant Base
EDIT:
As clarified in comments, you actually don't need to add anything to autoload_paths. It's default behaviour for Zeitwerk in Rails when your place your code under some subdirectory in app.
Original answer:
I'm posting separate answer, but actually accepted answer has all the good information. Since my comment was bigger than allowed, I chose to add separate answer for those who are struggling with similar issue.
We have created "components" under app where we separate domain specific namespaces/packages. They co-exists with some "non-component" Rails parts, that are hard to move under components. With classic autoloader, we have added #{config.root}/app in our autoload_paths.
This setup fails for Zeitwerk and removing "#{config.root}/app" from autoload_paths didn't help. rmlockerd suggestion to move app/api/ under /app/api/api moved me thinking in creating separate 'app/components' and moving all components under this directory and add this path to autoload_paths. Zeitwerk likes this.
I use carrierwave 0.9.0 with Rails 4 and I'm trying to make a custom error message. After doing some search, I found this answer:
en:
errors:
messages:
extension_white_list_error: 'My Custom Message'
I tried this by going to config/locales/en.yml then adding the code above, but nothing changed. The error message is still the same.
There is also the same issue on github here, but no answers, I think this problem is specific just with Rails 4 but not sure, have you the same problem when you use Rails 4?
There seem be some loading issue with Rails 4.0 with regards to i18n files
Ideally what should be I18n load paths as per 3+
/Users/joshianiket22/.rvm/gems/ruby-1.9.3-p327#rails3_2/gems/activesupport-4.0.0/lib/active_support/locale/en.yml
/Users/joshianiket22/.rvm/gems/ruby-1.9.3-p327#rails3_2/gems/activemodel-4.0.0/lib/active_model/locale/en.yml
/Users/joshianiket22/.rvm/gems/ruby-1.9.3-p327#rails3_2/gems/activerecord-4.0.0/lib/active_record/locale/en.yml
/Users/joshianiket22/.rvm/gems/ruby-1.9.3-p327#rails3_2/gems/actionpack-4.0.0/lib/action_view/locale/en.yml
/Users/joshianiket22/.rvm/gems/ruby-1.9.3-p327#rails3_2/gems/carrierwave-0.9.0/lib/carrierwave/locale/en.yml
/Users/joshianiket22/carrierwave_tester/config/locales/en.yml
What is seen in Rails 4.0
/Users/joshianiket22/.rvm/gems/ruby-1.9.3-p327#rails3_2/gems/activesupport-3.2.11/lib/active_support/locale/en.yml
/Users/joshianiket22/.rvm/gems/ruby-1.9.3-p327#rails3_2/gems/activemodel-3.2.11/lib/active_model/locale/en.yml
/Users/joshianiket22/.rvm/gems/ruby-1.9.3-p327#rails3_2/gems/activerecord-3.2.11/lib/active_record/locale/en.yml
/Users/joshianiket22/.rvm/gems/ruby-1.9.3-p327#rails3_2/gems/actionpack-3.2.11/lib/action_view/locale/en.yml
/Users/joshianiket22/workspace/zenjavi/carrierwave_tester/config/locales/en.yml
/Users/joshianiket22/.rvm/gems/ruby-1.9.3-p327#rails3_2/gems/carrierwave-0.9.0/lib/carrierwave/validations/../locale/en.yml
One can clear see the difference between the two the carrierwave en.yml is loaded after a the application specific en.yml and there is your issue
I suggest there is no easy way unless you the change the load_paths in rails application and some how manage to change the order of load_paths of as expected
I have given a pull request over here. Completely at awe of Carrierwave guys to decide on it
Hacky Solution :
I was refraining in giving you this solution earlier but still if you want it that bad here what you can do
define a file in lib directory(let say auto_load_i18n.rb) and assign the lib path to autoload (in application.rb)
config.autoload_paths += %w(#{config.root}/lib)
Inside auto_load_i18n.rb write this
I18n.load_path.delete(Rails.root.join("config/locales/en.yml").to_s)
I18n.load_path << Rails.root.join("config/locales/en.yml").to_s
And require the lib file at the top of your application_controller.rb
require 'auto_load_i18n'
class ApplicationController < ActionController::Base
and I guess everything would work then
You can now understand as to why I was refraining in giving this as a possible solution :)
Hope this help
It's fixed now guys:
https://github.com/carrierwaveuploader/carrierwave/pull/1264
Thanks for the patience.
I use a rails 5.1
I created a file config/locales/carrierwave.ar.yml and wrote
ar:
carrierwave:
errors:
messages:
min_size_error: "حجم الصورة لابد أن يكون أكبر من %{min_size}"
max_size_error: "حجم الصورة لابد أن يكون أقل من %{max_size}"
....
You can take a look at this file :)
I'm learning rails and I've come across a little quirk that I can't seem to find the answer to anywhere:
Since I'm learning rails, I'll make a few tweaks to the code while the localhost is running (rails s) and then just refresh the browser to see if the change I wanted to make was accurate. This works for changes to the views, css, html, routing, etc.
But now I'm making changes to a controller file that is calling another ruby class that I wrote and when I make changes to the ruby class, they don't show up right away. The way I know this is that I use a variety of printf functions in the Ruby class to show the current state of things and if I add one and re-run, it won't show unless I shut the server down and restart it.
Any thoughts? Is this a known issue?
You must autoload the folder which contains your custom files:
# in config/application.rb:
# Custom directories with classes and modules you want to be autoloadable.
config.autoload_paths += %W(#{config.root}/extras)
There you write the folder which you want to be autoloaded.
WARNING: the naming is very important: files in there must be named as the class/modules they define (like models, controllers, etc):
foo.rb must define Foo costant
foo/bar.rb must define Foo:Bar costant
and you cannot autoload files which do not have this naming convention. The reason is linked to the autoload working: when in your code call f.e. the Foo constant, and the constant is missing, Rails tries to see if in its autoload paths there is a file that follows this naming convention, and if there is it loads it.
I have seen this problem arise in many different circumstances and would like to get the best practices for fixing / debugging it on StackOverflow.
To use a real world example this occurred to me this morning:
expected announcement.rb to define Announcement
The class worked fine in development, testing and from a production console, but failed from in a production Mongrel. Here's the class:
class Announcement < ActiveRecord::Base
has_attachment :content_type => 'audio/mp3', :storage => :s3
end
The issue I would like addressed in the answers is not so much solving this specific problem, but how to properly debug to get Rails to give you a meaningful error as expected x.rb to define X.rb' is often a red herring...
Edit (3 great responses so far, each w/ a partial solution)
Debugging:
From Joe Van Dyk: Try accessing the model via a console on the environment / instance that is causing the error (in the case above: script/console production then type in 'Announcement'.
From Otto: Try setting a minimal plugin set via an initializer, eg: config.plugins = [ :exception_notification, :ssl_requirement, :all ] then re-enable one at a time.
Specific causes:
From Ian Terrell: if you're using attachment_fu make sure you have the correct image processor installed. attachment_fu will require it even if you aren't attaching an image.
From Otto: make sure you didn't name a model that conflicts with a built-in Rails class, eg: Request.
From Josh Lewis: make sure you don't have duplicated class or module names somewhere in your application (or Gem list).
That is a tricky one.
What generally works for me is to run "script/console production" on the production server, and type in:
Announcement
That will usually give you a better error message. But you said you already tried that?
I just ran into this error as well.
The short of it was that my rb file in my lib folder was not in a folder structure to match my module naming convention. This caused the ActiveSupport auto loader to use the wrong module to see if my class constant was defined.
Specifically I had defined the following class
module Foo
class Bar
end
end
In the root of /lib/bar.rb
This caused the autoloader to ask module Object if Bar was defined instead of module Foo.
Moving my rb file to /lib/foo/bar.rb fixed this problem.
I've encountered this before, and the AttachmentFu plugin was to blame. I believe in my case it was due to AttachmentFu expecting a different image processor than what was available, or non-supported versions were also installed. The problem was solved when I explicitly added :with => :rmagick (or similar -- I was using RMagick) to the has_attachment method call even for non-image attachments. Obviously, make sure that your production environment has all the right gems (or freeze them into your application) and supporting software (ImageMagick) installed. YMMV.
As for not getting Rails and AttachmentFu to suck up and hide the real error -- we fixed it before figuring it out completely.
Since this is still the top Google result, I thought I'd share what fixed the problem for me:
I had a module in the lib folder with the exact same name as my application. So, I had a conflict in module names, but I also had a conflict of folder names (not sure if the latter actually makes a difference though).
So, for the OP, make sure you don't have duplicated class or module names somewhere in your application (or Gem list).
For me, the cause was a circular dependency in my class definitions, and the problem only showed up using autotest in Rails. In my case, I didn't need the circular dependency, so I simply removed it.
You can try disabling all your plugins and add them back in one by one.
In environment.rb in the Initalizer section, add a line like this one:
config.plugins = [ :exception_notification, :ssl_requirement, :all ]
Start with the minimum set to run your application and add them in one by one. I usually get this error when I've defined a model that happens to map to an existing filename. For example, a Request model but Rails already has a request.rb that gets loaded first.
I had this problem for a while and in my case the error was always preceded from this S3 error:
(AWS::S3::Operation Aborted) "A
conflicting conditional operation is
currently in progress against this
resource. Please try again."
This problem usually occurs when creating the same bucket over and over again. (Source AWS Developers forum)
This was due to the fact that I had used attachment_fu to create the bucket and I had decommented the line containing the command Bucket.create(##bucket_name) in lib/technoweenie/attachment_fu/backends/s3_backends.rb (near to line 152).
Once commented or deleted the command Bucket.create(##bucket_name) the problem disappeared.
I hope this helps.
Changing class names while using STI caused this for me:
Class changed from 'EDBeneficiary' to 'EdBeneficiary'
Existing records had 'EDBeneficiary' stored in the 'type' column, so when Rails tried to load them up the exception was raised.
Fix: Run a migration to update values in the 'type' column to match the new class name.
in my case, I am getting this error in the development console but I can load the class in irb
Sorry this isn't a definitive answer, but another approach that might work in some specific circumstance:
I just ran in to this problem while debugging a site using Ruby 1.8.7 and Merb 1.0.15. It seemed that the class in question (let's call it SomeClass) was falling out of scope, but when some_class.rb file was automatically loaded, the other files it required (some_class/base.rb etc) were not loaded by the require mechanism. Possibly a bug in require?
If I required some_class file earlier, such as the end of environment.rb, it seems to prevent the object falling out of scope.
I was getting this error duo to a controller definition being in a file that wasn't named as a controller. For instance, you have a Comment model and you define the controller in a comment.rb file instead of comments_controller.rb
I had this problem with rails version 1.2.3. I could reproduce the problem only with mongrel, using console environment access didn't give any useful info. In my case, I solved making the RAILS_ROOT/html folder writable by mongrel and then restarting the web server, as some users reported here:
http://www.ruby-forum.com/topic/77708
When I upgraded rails from 1.1.6 to 1.2.6 and 2.0.5 for my app, I faced this error. In short, old plugins caused this error. These plugins were already out-dated and no update anymore (even no repo!). After I removed them, the app worked on 1.2.6 and 2.0.5. But I didn't check the detail source code of the plugins.