Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clockwork on Heroku is failing to load #83

Closed
kapso opened this issue Sep 20, 2019 · 5 comments
Closed

Clockwork on Heroku is failing to load #83

kapso opened this issue Sep 20, 2019 · 5 comments

Comments

@kapso
Copy link

kapso commented Sep 20, 2019

Clockwork Gem - https://github.com/Rykian/clockwork

Getting this error - ! Unable to load application: NameError: expected file /app/lib/clock.rb to define constant Clock, but didn't

My clock.rb is inside - /APP_ROOT/lib/clock.rb, and not in /APP_ROOT/app/lib/clock.rb

This is my environment on Heroku -

  • Rails v6.0
  • Ruby v2.6.4
  • Zeitwerk v2.1.10

Detailed Error -

2019-09-20T01:16:52.504423+00:00 app[web.1]: ! Unable to load application: NameError: expected file /app/lib/clock.rb to define constant Clock, but didn't
2019-09-20T01:16:52.504612+00:00 app[web.1]: bundler: failed to load command: puma (/app/vendor/bundle/ruby/2.6.0/bin/puma)
2019-09-20T01:16:52.504669+00:00 app[web.1]: NameError: expected file /app/lib/clock.rb to define constant Clock, but didn't
2019-09-20T01:16:52.504672+00:00 app[web.1]: /app/vendor/bundle/ruby/2.6.0/gems/zeitwerk-2.1.10/lib/zeitwerk/loader/callbacks.rb:17:in `on_file_autoloaded'
2019-09-20T01:16:52.504674+00:00 app[web.1]: /app/vendor/bundle/ruby/2.6.0/gems/zeitwerk-2.1.10/lib/zeitwerk/kernel.rb:17:in `block in require'
2019-09-20T01:16:52.504678+00:00 app[web.1]: /app/vendor/bundle/ruby/2.6.0/gems/zeitwerk-2.1.10/lib/zeitwerk/kernel.rb:16:in `tap'
2019-09-20T01:16:52.504681+00:00 app[web.1]: /app/vendor/bundle/ruby/2.6.0/gems/zeitwerk-2.1.10/lib/zeitwerk/kernel.rb:16:in `require'

Adding more info here -

This issue is fixed if I use classic autoloader as suggested here - https://weblog.rubyonrails.org/2019/2/22/zeitwerk-integration-in-rails-6-beta-2/

config.autoloader = :classic

Also,
I have the following in application.rb - config.eager_load_paths += %W[#{config.root}/lib]

@fxn
Copy link
Owner

fxn commented Sep 20, 2019

From the description, I guess your application has lib in the autoload paths, and that lib/clock.rb defines Clockwork instead of Clock.

If that is right, you have two options:

  1. Remove lib from the autoload paths, which is something encouraged generally because lib normally has all sort of things that are not autoloadable (as Rake tasks, for example, or your own use case). In that case, changes in those files won't reload the app.
  2. If you absolutely want lib in autoload paths, then you need to say that lib/clock.rb should not really be managed by Zeitwerk: Rails.autoloaders.main.ignore("#{Rails.root}/lib/clock.rb").

@kapso
Copy link
Author

kapso commented Sep 20, 2019

@fxn

Yea I have the following in application.rb - because I have a bunch of helper code sitting in APP_ROOT/lib, that I want to be auto-loaded. Or perhaps in Rails 6 (due to zeitwerk), its better to have that code in app/lib/ ??

config.eager_load_paths += %W[#{config.root}/lib]

BTW, I renamed APP_ROOT/lib/clock.rb => APP_ROOT/lib/clockwork.rb and that fixed the issue.

@kapso kapso closed this as completed Sep 20, 2019
@kapso kapso reopened this Sep 20, 2019
@fxn
Copy link
Owner

fxn commented Sep 20, 2019

Oh, yes, if renaming the file is an option, that solves the problem too.

Regarding code organization, it all depends on the contents. Question is: Should all *.rb files under lib be autoloadable? If in your app that is true, then your configuration is good.

Otherwise, since lib is in $LOAD_PATH, people just require manually what they need where they need it.

I have also seen app/lib in some apps containing all stuff that has to be autoloaded and that does not belong to the rest of folders in app. That is another possibility.

The important bit is that if Zeitwerk is managing some particular directory, its (non-ignored) file and directory names should match the constants they define. Not doing that is an error condition.

@fxn
Copy link
Owner

fxn commented Sep 23, 2019

Hey @kapso, do you think we can close this one?

@fxn
Copy link
Owner

fxn commented Sep 25, 2019

I like to keep issues and PRs to 0 in this project. Since the original issue showed a mismatch in the file name and that has been solved, I believe we can close.

However, please feel free to followup if you'd like to discuss more about code organization.

@fxn fxn closed this as completed Sep 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants