Closed jrochkind closed 2 years ago
I'm running into the following error when trying to build Hyrax's docker images.
NoMethodError: undefined method `[]' for nil:NilClass
/usr/local/bundle/gems/qa-5.8.0/lib/qa/authorities/local.rb:20:in `subauthorities_path'
/usr/local/bundle/gems/qa-5.8.0/lib/qa/authorities/local.rb:29:in `names'
/usr/local/bundle/gems/qa-5.8.0/lib/qa/authorities/local.rb:61:in `register_defaults'
/usr/local/bundle/gems/qa-5.8.0/lib/qa/authorities/local.rb:41:in `block in registry'
/usr/local/bundle/gems/qa-5.8.0/lib/qa/authorities/local/registry.rb:6:in `initialize'
/usr/local/bundle/gems/qa-5.8.0/lib/qa/authorities/local.rb:40:in `new'
/usr/local/bundle/gems/qa-5.8.0/lib/qa/authorities/local.rb:40:in `registry'
/usr/local/bundle/gems/qa-5.8.0/lib/qa/authorities/local.rb:51:in `register_subauthority'
/app/samvera/hyrax-webapp/config/initializers/hyrax.rb:55:in `<main>'
This is happening when bundle exec rake assets:precompile
is run.
I played with different forms and the only I was seeing as working were Qa::Engine.config.before_initialize
and the original unwrapped form. This might have to do with the rake command being run in a production rails environment where cache_classes
is set to true
.
Sorry I'm off on Fridays so just going through all my messages and alerts and getting to this.
While we've already reverted the change thinking we didn't have the bandwidth...
For future reference, I think the answer would/could have been that the thing in your local hyrax-webapp/config/initializers/hyrax.rb:55
also needed to be wrapped in to_prepare
.
to_prepare
in an initialier when referencing autoloaded content was always a race condition that could fail unpredictably, but only with zeitwerk autoloader is it flagged and given a deprecation notice, with future zeitwerk to make it fail altogether. So this will have to be fixed as people upgrade to a zeitwerk that requires it.
My Rails 6.1.3.2 app that uses
qa
gem has this deprecation warning on startup in development mode:/Users/jrochkind/code/scihist_digicoll/config/environment.rb:5
is justRails.application.initialize!
.I haven't been able to reproduce this in a new fresh Rails 6.1.3.2 app -- I'm not sure what settings in my actual app are triggering this warning, when I can't get a fresh app too. I've spent some time trying.
However, it seems like this is a legit problem, that could affect other apps, and should be fixed. Here is the Rails Autoloading and Reloading Constants Guide.
The small change in this PR eliminates the deprecation warning for me. And I believe is appropriate for Rails.
Other possible changes could have been:
extend ActiveSupport::Autoload
in various places (they've been there for a long time), to opt-in to Rails autoloading for classes that would ordinarily not be auto-loaded. (I think engine classes are not autoloaded by default at all). i think that's the root of the problem, and I'm not sure if it's really a good idea or necessary -- but seemed like a bigger change than I wanted to make for now.Those might actually make sense, but I was nervous to try to make more than the smallest change that seemed to resolve the problem, which this is.
I have also confirmed:
to_prepare
blockRails.application.reloader
API was introduced in Rails 5.0.0, which is the oldest version of Rails that this gem currently supports, so it is available in all versions of this gem.The only thing that makes me nervous is I don't understand why I can't reproduce in stock from scratch app. Still, I think this change should be harmless and appropriate and will fix this problem -- unless someone would prefer we go removing all the
extend ActiveSupport::Autoload
sprinkled throughout the gem, which may actually be a more fundamental fix.