fxn / zeitwerk Goto Github PK

View Code? Open in Web Editor NEW

1.9K 24.0 118.0 782 KB

Efficient and thread-safe code loader for Ruby

License: MIT License

Ruby 99.96% Shell 0.04%

zeitwerk's People

Contributors

Stargazers

Watchers

Forkers

krzysiek1507 planas ricardotk002 why-el eregon yigger prathamesh-sonpatki zw963 edouard-chin svkmax cprodhomme matildasmeds y-yagi hkdnet aeroastro jcoyne byroot apuratepp weapp excid3 enda1111 klobuczek tricknotes kvokka mschnitzer meganemura joshpencheon mdesantis macio oyeyemidamilola cotsog ssabrii giraffate janbiedermann rakibulislam networkempire-55467-sclack-com fursich driedjackfr strech sanfrecce-osaka emmab morristech kjavier rafbm pvande bf4 nasutaro211 cafonso sachiotomita k44-ysmr bjfish marcrohloff mfilej isabella232 axcdnt nageshlop comhuhuan peterb chriscz some-forks cedricbm maniacs-oss shopify mifrill solnic searls teoljungberg osxgirl datenreisender vyncem kd-collective albertoalmagro wicky-andrian standardgalactic bearerpipelinetest waiting-for-dev tom-carter mussajoop flavono123 ghousemohamed twoodwark gmcgibbon icheishvili vsppedro guigs stevenharman alhafoudh thousand-rubies maths22 jeffmeyers okuramasafumi leehericks shioyama lvonk atolix gkarthk surgo martinemde henrik exoego

zeitwerk's Issues

uninitialized constant Concerns (NameError)

For version 2.1.7, when I run rails application as production mode like below
RAILS_ENV=production rails s

zeit raises exception like below
uninitialized constant Concerns (NameError)

It works fine on 2.1.6.

I only have .keep files under all concerns directories.

Clockwork on Heroku is failing to load

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]

Fallback for older Ruby versions

Could zeitwerk provide a fallback that would eager load everything (probably also with disabled reloading) on Ruby implementations which do not fulfill the zeitwerk's requirements? That would potentially allow for wider adoption.

I am considering to use it in concurrent-ruby. It still supports 1.9 so I need a fallback, I started thinking about adding fallback in concurrent-ruby however it seems it would be better and beneficial to have in the zeitwerk itself.

Error running an example from synopsis

Hi,

I'm playing with this gem by running an example from synopsis:

# lib/my_gem.rb
require "zeitwerk"
loader = Zeitwerk::Loader.for_gem
loader.setup

module MyGem
end

loader.eager_load

By running ruby lib/my_gem.rb I'm getting the below error.

ruby --version: ruby 2.5.5p157 (2019-03-15 revision 67260) [x86_64-darwin17]
gem list zeitwerk: zeitwerk (2.1.9)

Am I doing something wrong? Thanks!

Traceback (most recent call last):                 
        14: from lib/my_gem.rb:5:in `<main>'       
        13: from /Users/bruno/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/zeitwerk-2.1.9/lib/zeitwerk/kernel.rb:16:in `require'
        12: from /Users/bruno/.rbenv/versions/2.5.5/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
        11: from /Users/bruno/.rbenv/versions/2.5.5/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
        10: from /Users/bruno/data/edu/project/lib/my_gem.rb:2:in `<top (required)>'                  
         9: from /Users/bruno/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:442:in `for_gem'
         8: from /Users/bruno/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/zeitwerk-2.1.9/lib/zeitwerk/registry.rb:85:in `loader_for_gem'
         7: from /Users/bruno/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/zeitwerk-2.1.9/lib/zeitwerk/registry.rb:85:in `tap'
         6: from /Users/bruno/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/zeitwerk-2.1.9/lib/zeitwerk/registry.rb:88:in `block in loader_for_gem'
         5: from /Users/bruno/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:182:in `push_dir'
         4: from /Users/bruno/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:713:in `raise_if_conflicting_directory'
         3: from /Users/bruno/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:713:in `synchronize'
         2: from /Users/bruno/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:714:in `block in raise_if_conflicting_directory'
         1: from /Users/bruno/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:714:in `each'
/Users/bruno/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:717:in `block (2 levels) in raise_if_conflicting_directory': loader (Zeitwerk::Error)

#<Zeitwerk::Loader:0x00007fbf270f66d8
 @autoloaded_dirs=[],
 @autoloads={},
 @eager_load_exclusions=#<Set: {}>,
 @eager_loaded=false,
 @ignored_glob_patterns=#<Set: {}>,
 @ignored_paths=#<Set: {}>,
 @inflector=
  #<Zeitwerk::GemInflector:0x00007fbf270f61b0
   @version_file="/Users/bruno/data/edu/project/lib/my_gem/version.rb">,
 @initialized_at=2019-09-01 00:56:45 +0200,
 @lazy_subdirs={},
 @logger=nil,
 @mutex=#<Thread::Mutex:0x00007fbf270f6250>,
 @mutex2=#<Thread::Mutex:0x00007fbf270f6200>,
 @preloads=[],
 @reloading_enabled=false,
 @root_dirs={},
 @setup=false,
 @tag="my_gem",
 @to_unload={}>


wants to manage directory /Users/bruno/data/edu/project/lib, which is already managed by

#<Zeitwerk::Loader:0x00007fbf2710d978
 @autoloaded_dirs=[],
 @autoloads=
  {"/Users/bruno/data/edu/project/lib/my_gem.rb"=>[Object, :MyGem],
   "/Users/bruno/data/edu/project/lib/project"=>[Object, :Project]},
 @eager_load_exclusions=#<Set: {}>,
 @eager_loaded=false,
 @ignored_glob_patterns=#<Set: {}>,
 @ignored_paths=#<Set: {}>,
 @inflector=
  #<Zeitwerk::GemInflector:0x00007fbf2710d0e0
   @version_file="lib/my_gem/version.rb">,
 @initialized_at=2019-09-01 00:56:45 +0200,
 @lazy_subdirs={"Project"=>["/Users/bruno/data/edu/project/lib/project"]},
 @logger=nil,
 @mutex=#<Thread::Mutex:0x00007fbf2710d220>,
 @mutex2=#<Thread::Mutex:0x00007fbf2710d1d0>,
 @preloads=[],
 @reloading_enabled=false,
 @root_dirs={"/Users/bruno/data/edu/project/lib"=>true},
 @setup=true,
 @tag="my_gem",
 @to_unload={}>

Rails 6 installation issues

Oops! This was meant for the CamaleonCMS repo.

not autoreloading application helpers with rails

I don't know if this is coming from rails's setup or zeitwerk, so not sure but posting it here too just in case.

rails/rails#35978

Autoloading from subdirectory with same name as ruby file doesn't work

Autoloading doesn't seem to work with a file hierarchy like this:

app/models/book.rb          Book
app/models/book/bla.rb      Book::Bla < Book

How to reproduce:

mkdir /tmp/zw && cd /tmp/zw
rails new .
echo "class Book ; end" > app/models/book.rb
mkdir app/models/book
echo "class Book::Bla < Book ; end" > app/models/book/bla.rb
rails console

Then, trying to access Book::Bla does not autoload app/models/book/bla.rb:

Loading development environment (Rails 6.0.0.beta3)
2.5.1 :001 > Book
 => Book 
2.5.1 :002 > Book::Bla
Traceback (most recent call last):
        1: from (irb):2
NameError (uninitialized constant Book::Bla)

autoloading "Helpers-like" modules

Hi,

Here is the folder tree my gem has:

lib
├── active_storage
│   ├── openstack
│   │   ├── client
│   │   │   ├── authenticator
│   │   │   │   └── request.rb
│   │   │   ├── authenticator.rb
│   │   │   ├── storage
│   │   │   │   ├── delete_object.rb
│   │   │   │   ├── get_object.rb
│   │   │   │   ├── list_objects.rb
│   │   │   │   ├── object_store_url.rb
│   │   │   │   ├── put_object.rb
│   │   │   │   └── show_object_metadata.rb
│   │   │   └── storage.rb
│   │   ├── client.rb
│   │   ├── helpers
│   │   │   ├── cache_readerable.rb
│   │   │   ├── cacheable_body.rb
│   │   │   └── https_client.rb
│   │   ├── railtie.rb
│   │   └── version.rb
│   └── service
│       └── openstack_service.rb
└── activestorage_openstack.rb

In the activestorage_openstack.rb file I put:

require 'zeitwerk'
Zeitwerk::Loader.for_gem.setup

In the authenticator.rb file, I have:

require_relative '../helpers/cache_readerable'

module ActiveStorage
  module Openstack
    class Client
      class Authenticator
        include Helpers::CacheReaderable
        [...]
      end
    end
  end
end

I want to get rid of the require_relative directive but without it I get this error:

NameError:
  uninitialized constant ActiveStorage::Openstack::Helpers::CacheReaderable

Any suggestions?

Thank you for the work so far.

Question Conflict File Path with gem

Hi, I have question Conflict File Path with gem.

In my Rails project, I want to load Model class.
But raise uninitialized constant error.

I want to know best practices for conflict File Path with gem

For example:

# MyRailsApp/app/models/foo.rb in my Rails project
require "MyRailsApp/vendor/bundle/ruby/2.5.0/bundler/gems/hoge-gem/app/models/foo.rb"
class Foo
end

# vendor/bundle/ruby/2.5.0/bundler/gems/hoge-gem/app/models/foo.rb

class Foo
end

$ rails c
[1] pry(main)> Foo
NameError: uninitialized constant Foo
Did you mean?  Foo
from (pry):1:in `<main>'

I append infomation If loss of infomation.

Idea: Strict mode?

👋 I'm currently clearing up all the shadowed_files in our app, and I'm thinking: is a log actually enough? I'm concerned that users might re-introduce this kind of problems after I cleared them.

Feels to me that a shadowed file it's very likely to be indicative of an error, or at least not be what the user expect.

Is there legitimate reasons for files to be shadowed? Couldn't we more explicitly throw an error when it happens? Possibly as a Loader#strict = true option?

Loader error on ignored paths

Steps to reproduce:

# my_gem
loader = Zeitwerk::Loader.for_gem
loader.ignore 'lib/foo/bar'
loader.setup

Later, in another file:

# lib/foo/bar/zoo/my_file
loader = Zeitwerk::Loader.new
loader.push_dir "#{__dir__}/active_record" # <= raised here
loader.setup

It looks like the problem is in Loade::raise_if_conflicting_directory(dir) method. Don't you mind if I'll take it for PR?

Eager loading problem in version 2.1.5 (also in classic autoloader)

I have a few apps using Camaleon CMS, which is a Rails engine. When I tried to upgrade from Rails 5.2.3 to 6.0.0rc1, eager loading broke and the app won't boot with it turned on.

I realize this could be seen as an issue with Camaleon, but there appears to be a regression from 2.1.4 to 2.1.5.

I also was under the impression that setting the autoloader to :classic should preserve pre-6.0 behavior, but that is not the case as things that load fine in 5.2 do not load correctly in classic mode.

Symptoms:

not working with Zeitwerk 2.1.5
not working with config.autoloader = :classic
working with Zeitwerk 2.1.4 (non-classic mode only)

Repro here: https://github.com/brian-kephart/zeitwerk_issue. Steps:

git clone https://github.com/brian-kephart/zeitwerk_issue.git
bundle
rails s (app should boot)
comment out the zeitwerk entry in the Gemfile and bundle update zeitwerk, or uncomment config.autoloader = :classic in application.rb, and the app will no longer boot.

Disappearing instance methods

During upgrade to Rails 6.0.0.beta2 I found a problem with zeitwerk autoloader, which results in non present instance methods on controller that actually is defined and works fine with "classic" autoloader.

I reproduced it here https://github.com/morgoth/bug with steps described in the readme.

Maybe it's more a Rails problem, but since it strictly connects with switching autoloader I'm opening it here.

Reloading, autoloading and thread safety

Hi there!

At first, thanks for such a great project! We're finally able to overcome Rails autoloading gotchas and, moreover, bring autoloading and reloading to our non-Rails projects.

Appreciate your outstanding work! I've watched your presentation on Stuart-Tech and was even more inspired.

At the moment I'm experimenting with Zeitwerk + Rack (Cuba). Autoloading works like a charm but I have an issue with code reloading in a multithreaded environment. The docs say that reloading itself is not thread-safe and it's my responsibility to coordinate it which definitely makes sense.

To be able to reload code between requests in Rack I've implemented a very trivial middleware:

  class Reloader
    def initialize(app, loader)
      @app = app
      @loader = loader
      @mutex = Mutex.new
    end

    def call(env)
      @mutex.synchronize { @loader.reload }
      @app.call(env)
    end
  end

Unfortunately, it doesn't help and I still see errors like that:

web_1      | 2019-05-15 04:36:43 +0000: Rack app error handling request { GET /sidekiq/stylesheets/bootstrap.css }
web_1      | #<ArgumentError: wrong number of arguments (given 0, expected 2)>
web_1      | /bundle/gems/zeitwerk-2.1.6/lib/zeitwerk/loader.rb:655:in `cpath'
web_1      | /bundle/gems/zeitwerk-2.1.6/lib/zeitwerk/loader/callbacks.rb:11:in `on_file_autoloaded'
web_1      | /bundle/gems/zeitwerk-2.1.6/lib/zeitwerk/kernel.rb:17:in `block in require'
web_1      | /bundle/gems/zeitwerk-2.1.6/lib/zeitwerk/kernel.rb:16:in `tap'
web_1      | /bundle/gems/zeitwerk-2.1.6/lib/zeitwerk/kernel.rb:16:in `require'
web_1      | /bundle/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:291:in `block in require'
web_1      | /bundle/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:257:in `load_dependency'
web_1      | /bundle/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:291:in `require'
web_1      | /app/config/routes.rb:24:in `block (3 levels) in <top (required)>'  # `SidekiqAdmin` class should be loaded on that line
# Unrelated stack

It happens because cref is not resolved from empty, for some reason, autoloads

It happens once and after that, there are code loading issues after the exception:

web_1      | Zeitwerk@ed7a8d: file /app/app/web/controllers/sidekiq_admin.rb is ignored because SidekiqAdmin is already defined

Does it mean that the autoloading is not thread-safe for some reason?

I assume that becasue when I wrap not only reloading, but also the constant loading in a lock, the problem goes away.

Simplified:

    def call(env)
      @mutex.synchronize do
         @loader.reload
         @app.call(env)
      end
    end

Autoload doesn't work in Rails 6 and app folder

Hello. I try to make the following naming pattern: app/api/endpoint.rb to resolve to Api::Endpoint.
I know, that this is a pretty uncommon pattern, but it works well on Rails 5.2 with the classic autoloader.

What I do:

    config.autoload_paths += Dir[Rails.root.join('app')]
    config.eager_load_paths += Dir[Rails.root.join('app')]

in my application.rb, but Api namespace can't be resolved, I get:

NameError (uninitialized constant Api)

It works well if I put api/endpoint.rb to the project root, add root folder to autoload_paths, as well, as If I put to app/lib/api/endpoint.rb.

irb(main):005:0> pp Rails.autoloaders.main
#<Zeitwerk::Loader:0x00007ff9792b07a8
 @autoloaded_dirs=[],
 @autoloads=
  {"/home/sergiy/Work/Doormat/doormat-server/app/javascript"=>
    [Object, :Javascript],
   "/home/sergiy/Work/Doormat/doormat-server/app/views"=>[Object, :Views],
   "/home/sergiy/Work/Doormat/doormat-server/app/assets"=>[Object, :Assets],
   "/home/sergiy/Work/Doormat/doormat-server/app/api/root.rb"=>[Object, :Root],
   "/home/sergiy/Work/Doormat/doormat-server/app/channels/application_cable"=>
    [Object, :ApplicationCable],
   "/home/sergiy/Work/Doormat/doormat-server/app/controllers/application_controller.rb"=>
    [Object, :ApplicationController],
   "/home/sergiy/Work/Doormat/doormat-server/app/helpers/application_helper.rb"=>
    [Object, :ApplicationHelper],
   "/home/sergiy/Work/Doormat/doormat-server/app/jobs/application_job.rb"=>
    [Object, :ApplicationJob],
   "/home/sergiy/Work/Doormat/doormat-server/app/mailers/application_mailer.rb"=>
    [Object, :ApplicationMailer],
   "/home/sergiy/Work/Doormat/doormat-server/app/models/application_record.rb"=>
    [Object, :ApplicationRecord],
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/grape-swagger-rails-0.3.1/app/controllers/grape_swagger_rails/application_controller.rb"=>
    [GrapeSwaggerRails, :ApplicationController],
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/actiontext-6.0.0.rc1/app/helpers/action_text/tag_helper.rb"=>
    [ActionText, :TagHelper],
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/actiontext-6.0.0.rc1/app/helpers/action_text/content_helper.rb"=>
    [ActionText, :ContentHelper],
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/actiontext-6.0.0.rc1/app/models/action_text/rich_text.rb"=>
    [ActionText, :RichText],
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/actionmailbox-6.0.0.rc1/app/controllers/action_mailbox/ingresses"=>
    [ActionMailbox, :Ingresses],
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/actionmailbox-6.0.0.rc1/app/controllers/action_mailbox/base_controller.rb"=>
    [ActionMailbox, :BaseController],
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/actionmailbox-6.0.0.rc1/app/controllers/rails/conductor"=>
    [Rails, :Conductor],
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/actionmailbox-6.0.0.rc1/app/jobs/action_mailbox/incineration_job.rb"=>
    [ActionMailbox, :IncinerationJob],
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/actionmailbox-6.0.0.rc1/app/jobs/action_mailbox/routing_job.rb"=>
    [ActionMailbox, :RoutingJob],
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/actionmailbox-6.0.0.rc1/app/models/action_mailbox/inbound_email.rb"=>
    [ActionMailbox, :InboundEmail],
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activestorage-6.0.0.rc1/app/controllers/active_storage/direct_uploads_controller.rb"=>
    [ActiveStorage, :DirectUploadsController],
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activestorage-6.0.0.rc1/app/controllers/active_storage/base_controller.rb"=>
    [ActiveStorage, :BaseController],
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activestorage-6.0.0.rc1/app/controllers/active_storage/disk_controller.rb"=>
    [ActiveStorage, :DiskController],
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activestorage-6.0.0.rc1/app/controllers/active_storage/blobs_controller.rb"=>
    [ActiveStorage, :BlobsController],
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activestorage-6.0.0.rc1/app/controllers/active_storage/representations_controller.rb"=>
    [ActiveStorage, :RepresentationsController],
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activestorage-6.0.0.rc1/app/controllers/concerns/active_storage/set_current.rb"=>
    [ActiveStorage, :SetCurrent],
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activestorage-6.0.0.rc1/app/controllers/concerns/active_storage/set_blob.rb"=>
    [ActiveStorage, :SetBlob],
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activestorage-6.0.0.rc1/app/jobs/active_storage/purge_job.rb"=>
    [ActiveStorage, :PurgeJob],
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activestorage-6.0.0.rc1/app/jobs/active_storage/base_job.rb"=>
    [ActiveStorage, :BaseJob],
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activestorage-6.0.0.rc1/app/jobs/active_storage/analyze_job.rb"=>
    [ActiveStorage, :AnalyzeJob],
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activestorage-6.0.0.rc1/app/models/active_storage/current.rb"=>
    [ActiveStorage, :Current],
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activestorage-6.0.0.rc1/app/models/active_storage/blob.rb"=>
    [ActiveStorage, :Blob],
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activestorage-6.0.0.rc1/app/models/active_storage/attachment.rb"=>
    [ActiveStorage, :Attachment],
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activestorage-6.0.0.rc1/app/models/active_storage/filename.rb"=>
    [ActiveStorage, :Filename],
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activestorage-6.0.0.rc1/app/models/active_storage/variation.rb"=>
    [ActiveStorage, :Variation],
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activestorage-6.0.0.rc1/app/models/active_storage/preview.rb"=>
    [ActiveStorage, :Preview],
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activestorage-6.0.0.rc1/app/models/active_storage/variant.rb"=>
    [ActiveStorage, :Variant]},
 @eager_load_exclusions=#<Set: {}>,
 @eager_loaded=false,
 @ignored=#<Set: {}>,
 @ignored_paths=#<Set: {}>,
 @inflector=ActiveSupport::Dependencies::ZeitwerkIntegration::Inflector,
 @initialized_at=2019-06-29 17:10:40 +0300,
 @lazy_subdirs=
  {"Javascript"=>["/home/sergiy/Work/Doormat/doormat-server/app/javascript"],
   "Views"=>["/home/sergiy/Work/Doormat/doormat-server/app/views"],
   "Assets"=>["/home/sergiy/Work/Doormat/doormat-server/app/assets"],
   "ApplicationCable"=>
    ["/home/sergiy/Work/Doormat/doormat-server/app/channels/application_cable"],
   "ActionMailbox::Ingresses"=>
    ["/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/actionmailbox-6.0.0.rc1/app/controllers/action_mailbox/ingresses"],
   "Rails::Conductor"=>
    ["/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/actionmailbox-6.0.0.rc1/app/controllers/rails/conductor"],
   "ActionMailbox::InboundEmail"=>
    ["/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/actionmailbox-6.0.0.rc1/app/models/action_mailbox/inbound_email"],
   "ActiveStorage::Blob"=>
    ["/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activestorage-6.0.0.rc1/app/models/active_storage/blob"]},
 @logger=nil,
 @mutex=#<Thread::Mutex:0x00007ff9792b03c0>,
 @mutex2=#<Thread::Mutex:0x00007ff9792b0398>,
 @preloads=[],
 @reloading_enabled=true,
 @root_dirs=
  {"/home/sergiy/Work/Doormat/doormat-server/app"=>true,
   "/home/sergiy/Work/Doormat/doormat-server/app/api"=>true,
   "/home/sergiy/Work/Doormat/doormat-server/app/channels"=>true,
   "/home/sergiy/Work/Doormat/doormat-server/app/controllers"=>true,
   "/home/sergiy/Work/Doormat/doormat-server/app/controllers/concerns"=>true,
   "/home/sergiy/Work/Doormat/doormat-server/app/helpers"=>true,
   "/home/sergiy/Work/Doormat/doormat-server/app/jobs"=>true,
   "/home/sergiy/Work/Doormat/doormat-server/app/mailers"=>true,
   "/home/sergiy/Work/Doormat/doormat-server/app/models"=>true,
   "/home/sergiy/Work/Doormat/doormat-server/app/models/concerns"=>true,
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/grape-swagger-rails-0.3.1/app/controllers"=>
    true,
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/actiontext-6.0.0.rc1/app/helpers"=>
    true,
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/actiontext-6.0.0.rc1/app/models"=>
    true,
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/actionmailbox-6.0.0.rc1/app/controllers"=>
    true,
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/actionmailbox-6.0.0.rc1/app/jobs"=>
    true,
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/actionmailbox-6.0.0.rc1/app/models"=>
    true,
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activestorage-6.0.0.rc1/app/controllers"=>
    true,
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activestorage-6.0.0.rc1/app/controllers/concerns"=>
    true,
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activestorage-6.0.0.rc1/app/jobs"=>
    true,
   "/home/sergiy/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activestorage-6.0.0.rc1/app/models"=>
    true},
 @setup=true,
 @shadowed_files=#<Set: {}>,
 @tag="rails.main",
 @to_unload={}>

Loader wants to manage directory which is already managed

I have two gems. One called dor-services which knows nothing of zeitwerk and one called dor-services-client. The latter is a dependency of the former. The latter does use zeitwerk. When I run tests for dor-services I now get:

Failure/Error: require 'dor/services/client'

Zeitwerk::Error:
  loader

  #<Zeitwerk::Loader:0x00007fdd1e44f2e8
   @autoloaded_dirs=[],
   @autoloads={},
   @eager_load_exclusions=#<Set: {}>,
   @eager_loaded=false,
   @ignored=#<Set: {}>,
   @ignored_paths=#<Set: {}>,
   @inflector=#<DorServicesClientInflector:0x00007fdd1e44ef78>,
   @initialized_at=2019-05-23 15:53:38 -0500,
   @lazy_subdirs={},
   @logger=nil,
   @mutex=#<Thread::Mutex:0x00007fdd1e44efc8>,
   @mutex2=#<Thread::Mutex:0x00007fdd1e44efa0>,
   @preloads=[],
   @reloading_enabled=false,
   @root_dirs={},
   @setup=false,
   @shadowed_files=#<Set: {}>,
   @tag="1157b8",
   @to_unload={}>


  wants to manage directory /Users/jcoyne85/workspace/sul-dlss/dor-services/lib, which is already managed by

  #<Zeitwerk::Loader:0x00007fdd1d887c30
   @autoloaded_dirs=[],
   @autoloads=
    {"/Users/jcoyne85/workspace/sul-dlss/dor-services/lib/tasks"=>
      [Object, :Tasks],
     "/Users/jcoyne85/workspace/sul-dlss/dor-services/lib/dor/indexers"=>
      [Dor, :Indexers],
     "/Users/jcoyne85/workspace/sul-dlss/dor-services/lib/dor/exceptions.rb"=>
      [Dor, :Exceptions],
     "/Users/jcoyne85/workspace/sul-dlss/dor-services/lib/dor/utils"=>
      [Dor, :Utils],
     "/Users/jcoyne85/workspace/sul-dlss/dor-services/lib/dor/models"=>
      [Dor, :Models],
     "/Users/jcoyne85/workspace/sul-dlss/dor-services/lib/dor/workflow"=>
      [Dor, :Workflow],
     "/Users/jcoyne85/workspace/sul-dlss/dor-services/lib/dor/release_tags.rb"=>
      [Dor, :ReleaseTags],
     "/Users/jcoyne85/workspace/sul-dlss/dor-services/lib/dor/config.rb"=>
      [Dor, :Config],
     "/Users/jcoyne85/workspace/sul-dlss/dor-services/lib/dor/version.rb"=>
      [Dor, :Version],
     "/Users/jcoyne85/workspace/sul-dlss/dor-services/lib/dor/services"=>
      [Dor, :Services],
     "/Users/jcoyne85/workspace/sul-dlss/dor-services/lib/dor/datastreams"=>
      [Dor, :Datastreams]},
   @eager_load_exclusions=#<Set: {}>,
   @eager_loaded=false,
   @ignored=#<Set: {}>,
   @ignored_paths=#<Set: {}>,
   @inflector=#<DorServicesClientInflector:0x00007fdd1d8877a8>,
   @initialized_at=2019-05-23 15:53:37 -0500,
   @lazy_subdirs=
    {"Tasks"=>["/Users/jcoyne85/workspace/sul-dlss/dor-services/lib/tasks"],
     "Dor::Indexers"=>
      ["/Users/jcoyne85/workspace/sul-dlss/dor-services/lib/dor/indexers"],
     "Dor::Utils"=>
      ["/Users/jcoyne85/workspace/sul-dlss/dor-services/lib/dor/utils"],
     "Dor::Models"=>
      ["/Users/jcoyne85/workspace/sul-dlss/dor-services/lib/dor/models"],
     "Dor::Workflow"=>
      ["/Users/jcoyne85/workspace/sul-dlss/dor-services/lib/dor/workflow"],
     "Dor::ReleaseTags"=>
      ["/Users/jcoyne85/workspace/sul-dlss/dor-services/lib/dor/release_tags"],
     "Dor::Services"=>
      ["/Users/jcoyne85/workspace/sul-dlss/dor-services/lib/dor/services"],
     "Dor::Datastreams"=>
      ["/Users/jcoyne85/workspace/sul-dlss/dor-services/lib/dor/datastreams"]},
   @logger=nil,
   @mutex=#<Thread::Mutex:0x00007fdd1d8877f8>,
   @mutex2=#<Thread::Mutex:0x00007fdd1d8877d0>,
   @preloads=[],
   @reloading_enabled=false,
   @root_dirs={"/Users/jcoyne85/workspace/sul-dlss/dor-services/lib"=>true},
   @setup=false,
   @shadowed_files=
    #<Set: {"/Users/jcoyne85/workspace/sul-dlss/dor-services/lib/dor/certificate_authenticated_rest_resource_factory.rb",
     "/Users/jcoyne85/workspace/sul-dlss/dor-services/lib/dor/rest_resource_factory.rb"}>,
   @tag="8029fe",
   @to_unload={}>

Add Rubocop

May be it is a good time to add Rubocop?

Zeitwerk trying to autoload YAML files since 2.1.9

Since upgrading to Rails 6 from 6.rc2, I'm getting an error whereby Zeitwerk is truing to autoload a YAML file placed in `my-rails-app/some-dir/some-subdir/1-my-file.yml.

Framework trace is:

NameError: wrong constant name 1-my-file
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:705:in `const_defined?'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:705:in `cdef?'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:610:in `strict_autoload_path'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:587:in `autoload_for?'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:501:in `autoload_subdir'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:490:in `block in set_autoloads_in_dir'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:662:in `block in ls'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:659:in `foreach'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:659:in `ls'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:476:in `set_autoloads_in_dir'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader/callbacks.rb:67:in `block in on_namespace_loaded'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader/callbacks.rb:66:in `each'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader/callbacks.rb:66:in `on_namespace_loaded'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader/callbacks.rb:52:in `block in on_dir_autoloaded'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader/callbacks.rb:39:in `synchronize'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader/callbacks.rb:39:in `on_dir_autoloaded'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.9/lib/zeitwerk/kernel.rb:20:in `require'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:355:in `const_get'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:355:in `block (2 levels) in eager_load'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:662:in `block in ls'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:659:in `foreach'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:659:in `ls'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:346:in `block in eager_load'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:338:in `synchronize'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:338:in `eager_load'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:449:in `each'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:449:in `eager_load_all'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/application/finisher.rb:122:in `block in <module:Finisher>'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/initializable.rb:32:in `instance_exec'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/initializable.rb:32:in `run'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/initializable.rb:61:in `block in run_initializers'
~/.rbenv/versions/2.6.3/lib/ruby/2.6.0/tsort.rb:228:in `block in tsort_each'
~/.rbenv/versions/2.6.3/lib/ruby/2.6.0/tsort.rb:350:in `block (2 levels) in each_strongly_connected_component'
~/.rbenv/versions/2.6.3/lib/ruby/2.6.0/tsort.rb:431:in `each_strongly_connected_component_from'
~/.rbenv/versions/2.6.3/lib/ruby/2.6.0/tsort.rb:349:in `block in each_strongly_connected_component'
~/.rbenv/versions/2.6.3/lib/ruby/2.6.0/tsort.rb:347:in `each'
~/.rbenv/versions/2.6.3/lib/ruby/2.6.0/tsort.rb:347:in `call'
~/.rbenv/versions/2.6.3/lib/ruby/2.6.0/tsort.rb:347:in `each_strongly_connected_component'
~/.rbenv/versions/2.6.3/lib/ruby/2.6.0/tsort.rb:226:in `tsort_each'
~/.rbenv/versions/2.6.3/lib/ruby/2.6.0/tsort.rb:205:in `tsort_each'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/initializable.rb:60:in `run_initializers'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/application.rb:363:in `initialize!'

Unclear why the main module should be defined after Zeitwerk setup

The README has the following example code:

zeitwerk/README.md

Lines 59 to 69 in 757dd73

 # lib/my_gem.rb (main file) 

 require "zeitwerk" 

 loader = Zeitwerk::Loader.for_gem 

 loader.setup # ready! 

 module MyGem 

 # ... 

 end 

 loader.eager_load # optionally

Is there any reason for the main module to be declared after Zeitwerk setup? I'm asking that because it prevents gem developers to have the Zeitwerk setup in another file under the main module namespace, like this:

# lib/mygem.rb

module MyGem
end

require 'zeitwerk'
require 'mygem/zeitwerk_inflector'

loader = Zeitwerk::Loader.for_gem
zeitwerk_inflector_abs_path = "#{__dir__}/mygem/zeitwerk_inflector.rb"
loader.inflector = MyGem::ZeitwerkInflector.new
loader.ignore zeitwerk_inflector_abs_path
loader.setup

# lib/mygem/zeitwerk_inflector.rb

class MyGem::ZeitwerkInflector < Zeitwerk::Inflector
  def camelize(basename, _abspath)
    case basename
    when 'mygem'
      'MyGem'
    else
      super
    end
  end
end

Actually, I'm using the setup above in one of my projects and I haven't noticed any issues so far, so I wonder if the instructions order in the example is just accidental or not.

Also, I wonder if loader.eager_load order instruction is accidental or not too 😕

Autoloads not set when new `namespaces` are loaded

Hi @fxn !

I'm playing around with Rails 6.0.0.beta2 and came across this error where
constants inside of a ruby namespace are not being loaded by zeitwerk.

I spent some time debugging this error and it seems like bootsnap is preventing
TracePoint.new(:class) calls from being triggered so zeitwerk doesn't not
set autoloads for constants under that namespace.

Here are some simple steps to reproduce that error and how I was able to make it
run by not requiring bootsnap/setup.

Thank for your amazing work on this project.

Create a brand new rails app*

rails new zeitwerk
cd zeitwerk

Create Admin::Test class*

mkdir app/models/admin
echo 'class Admin; end' > app/models/admin.rb
echo 'class Admin::Test; end' > app/models/admin/test.rb

Enable zeitwerk logger*

echo 'Rails.autoloaders.logger = method(:puts)' >> config/application.rb

Try to print Admin::Test class name

DISABLE_SPRING=true rails runner 'puts Admin::Test.name'
[email protected]: autoload set for ApplicationCable, to be autovivified from /Users/jairovm/Sites/ruby/rails/tmp/zeitwerk/app/channels/application_cable
[email protected]: autoload set for ApplicationController, to be loaded from /Users/jairovm/Sites/ruby/rails/tmp/zeitwerk/app/controllers/application_controller.rb
[email protected]: autoload set for ApplicationHelper, to be loaded from /Users/jairovm/Sites/ruby/rails/tmp/zeitwerk/app/helpers/application_helper.rb
[email protected]: autoload set for ApplicationJob, to be loaded from /Users/jairovm/Sites/ruby/rails/tmp/zeitwerk/app/jobs/application_job.rb
[email protected]: autoload set for ApplicationMailer, to be loaded from /Users/jairovm/Sites/ruby/rails/tmp/zeitwerk/app/mailers/application_mailer.rb
[email protected]: autoload set for Admin, to be autovivified from /Users/jairovm/Sites/ruby/rails/tmp/zeitwerk/app/models/admin
[email protected]: autoload set for Admin, to be loaded from /Users/jairovm/Sites/ruby/rails/tmp/zeitwerk/app/models/admin.rb
[email protected]: autoload set for ApplicationRecord, to be loaded from /Users/jairovm/Sites/ruby/rails/tmp/zeitwerk/app/models/application_record.rb
[email protected]: autoload set for ActionText::TagHelper, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/actiontext-6.0.0.beta2/app/helpers/action_text/tag_helper.rb
[email protected]: autoload set for ActionText::ContentHelper, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/actiontext-6.0.0.beta2/app/helpers/action_text/content_helper.rb
[email protected]: autoload set for ActionText::RichText, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/actiontext-6.0.0.beta2/app/models/action_text/rich_text.rb
[email protected]: autoload set for ActionMailbox::BaseController, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/actionmailbox-6.0.0.beta2/app/controllers/action_mailbox/base_controller.rb
[email protected]: autoload set for ActionMailbox::Ingresses, to be autovivified from /usr/local/lib/ruby/gems/2.5.0/gems/actionmailbox-6.0.0.beta2/app/controllers/action_mailbox/ingresses
[email protected]: autoload set for Rails::Conductor, to be autovivified from /usr/local/lib/ruby/gems/2.5.0/gems/actionmailbox-6.0.0.beta2/app/controllers/rails/conductor
[email protected]: autoload set for ActionMailbox::IncinerationJob, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/actionmailbox-6.0.0.beta2/app/jobs/action_mailbox/incineration_job.rb
[email protected]: autoload set for ActionMailbox::RoutingJob, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/actionmailbox-6.0.0.beta2/app/jobs/action_mailbox/routing_job.rb
[email protected]: autoload set for ActionMailbox::InboundEmail, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/actionmailbox-6.0.0.beta2/app/models/action_mailbox/inbound_email.rb
[email protected]: autoload set for ActiveStorage::DirectUploadsController, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/controllers/active_storage/direct_uploads_controller.rb
[email protected]: autoload set for ActiveStorage::BaseController, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/controllers/active_storage/base_controller.rb
[email protected]: autoload set for ActiveStorage::BlobsController, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/controllers/active_storage/blobs_controller.rb
[email protected]: autoload set for ActiveStorage::RepresentationsController, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/controllers/active_storage/representations_controller.rb
[email protected]: autoload set for ActiveStorage::DiskController, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/controllers/active_storage/disk_controller.rb
[email protected]: autoload set for ActiveStorage::SetCurrent, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/controllers/concerns/active_storage/set_current.rb
[email protected]: autoload set for ActiveStorage::SetBlob, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/controllers/concerns/active_storage/set_blob.rb
[email protected]: autoload set for ActiveStorage::BaseJob, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/jobs/active_storage/base_job.rb
[email protected]: autoload set for ActiveStorage::AnalyzeJob, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/jobs/active_storage/analyze_job.rb
[email protected]: autoload set for ActiveStorage::PurgeJob, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/jobs/active_storage/purge_job.rb
[email protected]: autoload set for ActiveStorage::Variant, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/models/active_storage/variant.rb
[email protected]: autoload set for ActiveStorage::Blob, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/models/active_storage/blob.rb
[email protected]: autoload set for ActiveStorage::Filename, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/models/active_storage/filename.rb
[email protected]: autoload set for ActiveStorage::Variation, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/models/active_storage/variation.rb
[email protected]: autoload set for ActiveStorage::Attachment, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/models/active_storage/attachment.rb
[email protected]: autoload set for ActiveStorage::Current, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/models/active_storage/current.rb
[email protected]: autoload set for ActiveStorage::Preview, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/models/active_storage/preview.rb
[email protected]: constant Admin loaded from file /Users/jairovm/Sites/ruby/rails/tmp/zeitwerk/app/models/admin.rb
Please specify a valid ruby command or the path of a script to run.
Run 'rails runner -h' for help.

uninitialized constant Admin::Test

Disable bootsnap

sed -i '' "s/require 'bootsnap\/setup'/#require 'bootsnap\/setup'/g" config/boot.rb

Try again ( it worked this time )

DISABLE_SPRING=true rails runner 'puts Admin::Test.name'
[email protected]: autoload set for ApplicationCable, to be autovivified from /Users/jairovm/Sites/ruby/rails/tmp/zeitwerk/app/channels/application_cable
[email protected]: autoload set for ApplicationController, to be loaded from /Users/jairovm/Sites/ruby/rails/tmp/zeitwerk/app/controllers/application_controller.rb
[email protected]: autoload set for ApplicationHelper, to be loaded from /Users/jairovm/Sites/ruby/rails/tmp/zeitwerk/app/helpers/application_helper.rb
[email protected]: autoload set for ApplicationJob, to be loaded from /Users/jairovm/Sites/ruby/rails/tmp/zeitwerk/app/jobs/application_job.rb
[email protected]: autoload set for ApplicationMailer, to be loaded from /Users/jairovm/Sites/ruby/rails/tmp/zeitwerk/app/mailers/application_mailer.rb
[email protected]: autoload set for Admin, to be autovivified from /Users/jairovm/Sites/ruby/rails/tmp/zeitwerk/app/models/admin
[email protected]: autoload set for Admin, to be loaded from /Users/jairovm/Sites/ruby/rails/tmp/zeitwerk/app/models/admin.rb
[email protected]: autoload set for ApplicationRecord, to be loaded from /Users/jairovm/Sites/ruby/rails/tmp/zeitwerk/app/models/application_record.rb
[email protected]: autoload set for ActionText::TagHelper, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/actiontext-6.0.0.beta2/app/helpers/action_text/tag_helper.rb
[email protected]: autoload set for ActionText::ContentHelper, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/actiontext-6.0.0.beta2/app/helpers/action_text/content_helper.rb
[email protected]: autoload set for ActionText::RichText, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/actiontext-6.0.0.beta2/app/models/action_text/rich_text.rb
[email protected]: autoload set for ActionMailbox::BaseController, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/actionmailbox-6.0.0.beta2/app/controllers/action_mailbox/base_controller.rb
[email protected]: autoload set for ActionMailbox::Ingresses, to be autovivified from /usr/local/lib/ruby/gems/2.5.0/gems/actionmailbox-6.0.0.beta2/app/controllers/action_mailbox/ingresses
[email protected]: autoload set for Rails::Conductor, to be autovivified from /usr/local/lib/ruby/gems/2.5.0/gems/actionmailbox-6.0.0.beta2/app/controllers/rails/conductor
[email protected]: autoload set for ActionMailbox::IncinerationJob, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/actionmailbox-6.0.0.beta2/app/jobs/action_mailbox/incineration_job.rb
[email protected]: autoload set for ActionMailbox::RoutingJob, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/actionmailbox-6.0.0.beta2/app/jobs/action_mailbox/routing_job.rb
[email protected]: autoload set for ActionMailbox::InboundEmail, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/actionmailbox-6.0.0.beta2/app/models/action_mailbox/inbound_email.rb
[email protected]: autoload set for ActiveStorage::DirectUploadsController, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/controllers/active_storage/direct_uploads_controller.rb
[email protected]: autoload set for ActiveStorage::BaseController, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/controllers/active_storage/base_controller.rb
[email protected]: autoload set for ActiveStorage::BlobsController, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/controllers/active_storage/blobs_controller.rb
[email protected]: autoload set for ActiveStorage::RepresentationsController, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/controllers/active_storage/representations_controller.rb
[email protected]: autoload set for ActiveStorage::DiskController, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/controllers/active_storage/disk_controller.rb
[email protected]: autoload set for ActiveStorage::SetCurrent, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/controllers/concerns/active_storage/set_current.rb
[email protected]: autoload set for ActiveStorage::SetBlob, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/controllers/concerns/active_storage/set_blob.rb
[email protected]: autoload set for ActiveStorage::BaseJob, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/jobs/active_storage/base_job.rb
[email protected]: autoload set for ActiveStorage::AnalyzeJob, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/jobs/active_storage/analyze_job.rb
[email protected]: autoload set for ActiveStorage::PurgeJob, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/jobs/active_storage/purge_job.rb
[email protected]: autoload set for ActiveStorage::Variant, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/models/active_storage/variant.rb
[email protected]: autoload set for ActiveStorage::Blob, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/models/active_storage/blob.rb
[email protected]: autoload set for ActiveStorage::Filename, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/models/active_storage/filename.rb
[email protected]: autoload set for ActiveStorage::Variation, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/models/active_storage/variation.rb
[email protected]: autoload set for ActiveStorage::Attachment, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/models/active_storage/attachment.rb
[email protected]: autoload set for ActiveStorage::Current, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/models/active_storage/current.rb
[email protected]: autoload set for ActiveStorage::Preview, to be loaded from /usr/local/lib/ruby/gems/2.5.0/gems/activestorage-6.0.0.beta2/app/models/active_storage/preview.rb
[email protected]: autoload set for Admin::Test, to be loaded from /Users/jairovm/Sites/ruby/rails/tmp/zeitwerk/app/models/admin/test.rb
[email protected]: constant Admin loaded from file /Users/jairovm/Sites/ruby/rails/tmp/zeitwerk/app/models/admin.rb
[email protected]: constant Admin::Test loaded from file /Users/jairovm/Sites/ruby/rails/tmp/zeitwerk/app/models/admin/test.rb
Admin::Test

VERSIONS

bundle show rails                                                                                                                                                                             [18:14:54]
/usr/local/lib/ruby/gems/2.5.0/gems/rails-6.0.0.beta2

bundle show bootsnap                                                                                                                                                                          [18:14:15]
/usr/local/lib/ruby/gems/2.5.0/gems/bootsnap-1.4.1

bundle show zeitwerk                                                                                                                                                                          [18:15:11]
/usr/local/lib/ruby/gems/2.5.0/gems/zeitwerk-1.3.1

Append subdir to root namespace?

My use case is a gem. I would like to have the constants defined in its models/ directory belong to the root namespace, like so:

lib/my_gem.rb                         -> MyGem
lib/my_gem/models/flip.rb             -> MyGem::Flip
lib/my_gem/models/flop.rb             -> MyGem::Flop
lib/my_gem/models/concerns/widget.rb  -> MyGem::Widget
lib/my_gem/bar/flip.rb                -> MyGem::Bar::Flip
lib/my_gem/bar/flop.rb                -> MyGem::Bar::Flop

Is this possible?

Puzzling frozen array for unloadable_cpaths.

I'm not sure if this should be logged here or in ActiveSupport, given it's overlapping between the two… but also, I'm not entirely across the interplay of all of this anyway.

I've noticed that the value for unloadable_cpaths is a frozen array. This is passed through to Rails as the initial autoloaded_constants value in ActiveSupport::Dependencies - but the logic there modifies the provided array (with uniq! and concat calls in particular). At a high level, I'm finding this confusing - why provide a frozen object for something where modifications are expected?

On a more tangible/practical level: Thinking Sphinx (a gem I maintain) loads all files within app/indices (to find index definitions) using ActiveSupport::Dependencies.require_or_load file. When this occurs in Rails 6.0.0.rc1, a FrozenError crops up, because the underlying modifications to autoloaded_constants are being attempted on that initial frozen value (as noted in pat/thinking-sphinx#1137).

So: is this a bug in Zeitwerk/ActiveSupport? Or am I misusing/misunderstanding ActiveSupport::Dependencies in Thinking Sphinx? Or something else entirely? :)

Zeitwerk is not compatible with Rails Inflector

I have some defined acronyms in config/inflections.rb which are used in namespaces. Typically something like Id => ID

If I have the following concern app/models/concerns/my_acronym/test.rb where I have module MyACRONYM::Test. Then I include this concern in app/models/application_record.rb like include MyACRONYM::Test. With the classic autoloader it works but not with Zeitwerk. I'm getting uninitialized constant MyACRONYM::Test (NameError).

This happens after Rails 5.2 => 6.0 upgrade.

Reload from nested subdirectories

Hello there and thank you for the awesome work with this gem. I'm trying this on a non-rails project and have some issues with code-reloading. It loads the files just fine but wont reload them and I cannot see them in the @autoloads array.

My directory structure is:

apps
  web
    controllers
      books.rb

# apps/web/controllers/books.rb

module Web::Controllers
  class Books
    # ...
  end
end

My loader is setup like this:

loader = Zeitwerk::Loader.new
loader.push_dir("/path/to/lib")
loader.push_dir("/path/to/apps")
loader.setup

# And in a middleware I call (it's the same instance as the one above)
loader.reload

The files in lib gets reloaded but not in apps. If I would guess this has something to do with the "empty" namespace between Web::Controllers.

Am I missing something, has this something to do with the rails concerns compatibility?

This is what I get when I inspect the loader:

#<Zeitwerk::Loader:0x00007fdb978cf198 @inflector=#<Zeitwerk::Inflector:0x00007fdb978cf148>, @dirs={"/path/to/sandbox/lib"=>true, "/path/to/sandbox/apps"=>true}, @preloads=[], @ignored=#<Set: {}>, @autoloads={"/path/to/sandbox/lib/sandbox/message.rb"=>[Sandbox, "Message"], "/path/to/sandbox/apps/web"=>[Object, "Web"]}, @lazy_subdirs={"Web"=>["/path/to/sandbox/apps/web"]}, @eager_load_exclusions=#<Set: {}>, @mutex=#<Thread::Mutex:0x00007fdb978cef40>, @setup=true, @eager_loaded=false, @tracer=#<TracePoint:enabled>>

Failing with extension gem

Hi folks,

Given I have a extension gem (using dashes in the name), for example my-gem(My::Gem), how to correct setup the zeitwerk?

I made the following test and it's failing!

    files = [
      ["my/gem.rb", <<-EOS],
        $for_gem_test_loader = Zeitwerk::Loader.for_gem
        $for_gem_test_loader.enable_reloading
        $for_gem_test_loader.setup

        module My
          module Gem
          end
        end
      EOS
      ["my/gem/foo.rb", "class My::Gem::Foo; end"],
      ["my/gem/foo/bar.rb", "class My::Gem::Foo::Bar; end"]
    ]
    with_files(files) do
      with_load_path(".") do
        assert require "my/gem"
        assert My::Gem::Foo::Bar

        $for_gem_test_loader.unload
        assert !Object.const_defined?(:My::Gem)

        $for_gem_test_loader.setup
        assert My::Gem::Foo::Bar
      end
    end

% rake test                                                                                                                                                  *master zeitwerk

# Running tests with run options --seed 48021:

......................................................................E..........................................................................

Finished tests in 1.354945s, 107.0154 tests/s, 249.4567 assertions/s.


Error:
TestForGem#test_sets_my_gem_correctly:
NameError: uninitialized constant My::Gem::Foo
    /home/duke/src/oss/zeitwerk/test/lib/zeitwerk/test_for_gem.rb:49:in `block (3 levels) in <class:TestForGem>'
    /home/duke/src/oss/zeitwerk/test/support/loader_test.rb:70:in `with_load_path'
    /home/duke/src/oss/zeitwerk/test/lib/zeitwerk/test_for_gem.rb:47:in `block (2 levels) in <class:TestForGem>'
    /home/duke/src/oss/zeitwerk/test/support/loader_test.rb:61:in `block in with_files'
    /home/duke/src/oss/zeitwerk/test/support/loader_test.rb:54:in `chdir'
    /home/duke/src/oss/zeitwerk/test/support/loader_test.rb:54:in `with_files'
    /home/duke/src/oss/zeitwerk/test/lib/zeitwerk/test_for_gem.rb:46:in `block in <class:TestForGem>'

145 tests, 338 assertions, 0 failures, 1 errors, 0 skips
rake aborted!
Command failed with status (1)

Tasks: TOP => test
(See full trace by running task with --trace)

Can somebody help me to understand why zeitwerk aren't working? I'm making something wrong or it's a bug?

deleting a folder results in an error

absolutely not blocking but a bit interesting

I deleted my mailers folder and got this:

Errno::ENOENT
No such file or directory @ dir_initialize - /Users/localhostdotdev/src/my-app/app/mailers

Reload is not worked with roda.

Steps to reproduce

folder directory:

├── app.rb
├── config.ru
├── Gemfile
└── Gemfile.lock

content of config.ru

require 'roda'
require 'zeitwerk'

::Loader = Zeitwerk::Loader.new
::Loader.logger = method(:puts)
::Loader.push_dir(__dir__)
::Loader.setup

run App

content of app.rb

class App < Roda
  route do |r|
    p Loader.reload  # <= i am very ensure this code invoked repeatedly when send request.
    r.root do
      'hello1'
    end
  end
end

content of Gemfile

# frozen_string_literal: true

source "https://rubygems.org"

git_source(:github) {|repo_name| "https://github.com/#{repo_name}" }

gem "roda"
gem 'zeitwerk'

start up server

$: rackup
Zeitwerk@3ff636: autoload set for App, to be loaded from /home/zw963/Kid17/mastering_roda/my_app/app.rb
Zeitwerk@3ff636: constant App loaded from file /home/zw963/Kid17/mastering_roda/my_app/app.rb
[2019-03-17 00:52:12] INFO  WEBrick 1.4.2
[2019-03-17 00:52:12] INFO  ruby 2.6.1 (2019-01-30) [x86_64-linux]
[2019-03-17 00:52:12] INFO  WEBrick::HTTPServer#start: pid=29575 port=9292

first time visit http://127.0.0.1:9292/ in browser

logs:

Zeitwerk@eb920c: App unloaded
Zeitwerk@eb920c: autoload set for App, to be loaded from /home/zw963/Kid17/mastering_roda/my_app/app.rb
true
127.0.0.1 - - [17/Mar/2019:00:53:48 +0800] "GET / HTTP/1.1" 200 6 0.0013

i can see 'hello1' is print in browser, this expected behavior.

change code from 'hello1' to 'hello2' in app.rb, visit http://127.0.0.1:9292/ again

logs:

Zeitwerk@eb920c: autoload for App removed
Zeitwerk@eb920c: autoload set for App, to be loaded from /home/zw963/Kid17/mastering_roda/my_app/app.rb
true
127.0.0.1 - - [17/Mar/2019:00:54:53 +0800] "GET / HTTP/1.1" 200 6 0.0006

expected behavior

browser print "hello2"

actually behavior

browser no change, still "hello1"

Thanks

Performance issue in CI

Hi there!

I don't know if it's the right place for this issue, but Rails bug tracker is very busy so I open it here :)

My issue : I've tested my Rails app with Rails 6.0.0.beta2 and tried the new Zeitgest loader, and noticed that my test suite duration is twice longer than before (in Gitlab CI env) :/

The context :

I use grosser/parallel_tests to run the test suite with 6 cpus, and usually it takes 6/7mn to run.
Last week I introduced Zeitwerk in a bunch of gems I use (simple_navigation_bootstrap, active_settings) and noticed that the tests were a bit longer but didn't dig into it.
Finally, I've set up Zeitwerk in 9 gems that I use in this app, and noticed that the test suite was really longer : it took 12/13mn to run.
Now I use Zeitwerk in the Rails app and the test suite take 30mn to run 😢

By reverting the Rails loader to the classic mode it takes 13mn to run.

I could remove Zeitwerk in the gems I use and run some tests and I'm pretty sure it will solve the issue.
But I don't think it's the right direction to go.

Maybe I should eager load everything in CI env?

What do you think?

Thank you!

Namespaced models throw uninitialized constant

i have a little problem with my namespaced models:

# user/identity.rb
class User::Identity < ApplicationRecord
...
end

# user.rb
class User < ApplicationRecord
...
has_many :identities, class_name User::Identity.name
...
end

when i try to start the application with zeitwerk it throws this exeption

Uncaught exception: uninitialized constant User (call 'User.connection' to establish a connection)::Identity

It works with the classic loader. I have the same problem when i try to use a method on User::Identity in a method in the User class.
Do you have an idea? Is it a problem with my code, or in zeitwerk?

Greets
Marcel

QUESTION: convention for declaring name spaced classes

I posted this over on stackoverflow already but figured I might get more traction here.
Hopefully posting questions and not issues here is ok.

Curious what the preferred name spaced code should look like in rails 6 which uses zeitwerk for autoloading.

Previously I used:

# app/controllers/api/users_controller.rb
module Api
  class UsersController
    def index
      render json: {}
    end
  end 
end

With zeitwerk should we now use: ???

# app/controllers/api/users_controller.rb
class Api::UsersController
  def index
    render json: {}
  end 
end

Based on example in https://weblog.rubyonrails.org/2019/2/22/zeitwerk-integration-in-rails-6-beta-2/ it appears the 2nd style is being used.

By default rubocop will raise Style/ClassAndModuleChildren error with 2nd style and there are slight behavior differences:

module Foo
  class Bar
    def fud
    end
  end
end

module Foo
  class Woo
    def woo_woo
      Bar.new.fud
    end
  end
end

class Foo::Bar
  def fud
  end
end

class Foo::Woo
  def woo_woo
    # NameError: uninitialized constant Foo::Woo::Bar
    Bar.new.fud
    # no error
    Foo::Bar.new.fud
  end
end

From:
https://stackoverflow.com/questions/56675838/rails-6-convention-for-declaring-namespaced-classes-zeitwerk-autoloader

Code reloading issue with multiple classes inside a single file

Hello @fxn 👋 ,

Thanks a lot for Zeitwerk, it's a really cool gem.

I'm opening this issue to check if this is something Zeitwerk should support or our application is just not compliant with the file structure described by the Gem.

We have multiple files that have multiple classes inside, it's especially common for grouping error class inside a single file instead of having a bunch of files.

# application_error.rb

class ApplicationError < StandardError
end

class CustomError < ApplicationError
end

Zeitwerk has issues with reloading this and ruby will throw a TypeError: superclass mismatch for class CustomError. This make sense since CustomError was never marked for autoloading.

Here is a failing test

index dd69b8b..372ab87 100644
--- a/test/lib/zeitwerk/test_reloading.rb
+++ b/test/lib/zeitwerk/test_reloading.rb
@@ -18,6 +18,21 @@ class TestReloading < LoaderTest
     assert loader.reloading_enabled?
   end

+  test "superclass mismatch error" do
+    files = [
+      ["x.rb", "class X; end; class AnotherX < X; end"]
+    ]
+
+    with_setup(files) do
+      assert X
+      assert AnotherX
+
+      loader.reload
+
+      assert X
+    end
+  end
+
   test "reloading works if the flag is set" do
     files = [
       ["x.rb", "X = 1"],         # top-level

Happy to work on finding a fix if you consider that Zeitwerk should handle this case. Thanks!

Are there plans to support transitive module loading?

Hi,
I'm wondering whether it is a plan for zeitwerk to support searching the ancestor chain when reloading modules (or is this supported already?).

I tried reading the code, but unfortunately I'm not sure if I've fully grokked it.

What I am asking is will this gem currently fix rails/rails#28997, is that planned in the future, or is that not planned?

Thanks for the gem, looks like it will solve a lot of problems!

eager_load difference between autoloader classic, bug or feature?

Hi,

I noticed that when I used config.eager_load=true or ran the Jumpstart template in production which overrides the Devise helper https://github.com/excid3/jumpstart/blob/c6c0de0a9493c617297746ebef99a061f05c1518/app/helpers/devise_helper.rb it was not getting used. If I however switched to config.autoloader = :classic everything worked as expected.

Is this a bug or a feature?

Steps to reproduce:

Step 1:

rails new myapp -d postgresql -m https://raw.githubusercontent.com/excid3/jumpstart/c6c0de0/template.rb
cd myapp

Step 2:

foreman start
visit http://localhost:5000/users/sign_up
click the Sign up button and you will see a bootstrap error message above the form (which is correct).

Step 3:

kill foreman
change config.eager_load = true (or run in production) and repeat Step 2. You will notice it is no longer the bootstrap error defined here https://github.com/excid3/jumpstart/blob/c6c0de0a9493c617297746ebef99a061f05c1518/app/helpers/devise_helper.rb plus it is never loaded (which is wrong).

Step 4:

kill foreman
add config.autoloader = :classic to config/application.rb
Repeat Step 2 and it will be the correct boostrap error message again.

I'm going to also reference excid3/jumpstart#73 and loop in @excid3.

zeitwerk-2.1.9, ruby-2.5.5, Rails 6.0 upgrade uninitialized constant ApplicationJob (NameError)

First of all, thank you so much for tackling autoloading.

When upgrading a large Rails 5.2 app, I'm encountering the following:

.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:351:in const_get': uninitialized constant ApplicationJob (NameError) Did you mean? ApplicationJob

After enabling the log, it happens when zeitwerk starts loading the jobs folder in the Rails app.
The folder contains a file "application_job.rb" with the following content:
class ApplicationJob < ActiveJob::Base queue_as :default end

As this is a quite common pattern, I wonder what the correct way of declaration and usage of such Base Wrapper classes is in order for the autoloading to pick up on it. I also wonder, why the class name is picked up by the typo suggestion below the error output but not Zeitwerk.

Is this a matter of load order, do extensions of Rails Base classes need to be placed in a different namespace or loaded before-hand?

open class for override in reload case is not supported

ruby: 2.6.2
rails: 6.0.0.beta3

I have a model defined in my engine:

# app/models/rails_org/member.rb
class Member < ApplicationRecord
end

I overrided it in my main project

# app/models/member.rb
require 'rails_org/member'
class Member < ApplicationRecord
end

in reload case, only delete main model defined path from $LOADED_FEATURES

Sorry for my poor english, if need more information, please point out.

Enable auto-reloader, program behavior not inconsistent with disable it.

Steps to reproduce

folder directory:

├── app.rb
├── config.ru
├── Gemfile
└── Gemfile.lock

content of config.ru

# config.ru
require 'roda'
require 'zeitwerk'

loader = Zeitwerk::Loader.new
# loader.logger = method(:puts)
loader.push_dir(__dir__)
loader.setup

if ENV['RACK_ENV'] == 'production'
  Zeitwerk::Loader.eager_load_all
  run App
else
  run ->(env) {
    loader.reload
    App.call(env)
  }
end

content of app.rb

class App < Roda
  articles = []

  route do |r|
    r.post "articles" do
      articles << r.params["content"]
      "Count: #{articles.count}"
    end
  end
end

start server, and post http://127.0.0.1:9292/articles?content='content' repeatly.

Expected behavior

When no enable zeitwerk, We can see Following output:

POST articles?content='content'
# => Count: 1
POST articles?content='content'
# => Count: 2
POST articles?content='content'
# => Count: 3
...

Actual behavior

POST articles?content='content'
# => Count: 1
POST articles?content='content'
# => Count: 1
POST articles?content='content'
# => Count: 1
...

Unintuitive Inflector Behavior

You might want to consider using capitalize instead of capitalize! in Inflector.
capitalize! returns nil if nothing has been changed which causes an entire part of the name to be swallowed.
e.g. point_3d_value is camelized to PointValue

const_defined?': wrong constant name Font-awesome (NameError)

Hi we are using rails version 6.0.0 and when i run using rails version 6.0.0.rc1 its working fine
Error log
home/system/.rbenv/versions/2.6.1/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:705:inconst_defined?': wrong constant name Font-awesome (NameError)
`

Acronyms

What's the recommended way to define classes/modules that contain (or are entirely) acronyms?

For example (form 1):

lib/http.rb => Http
lib/smtp.rb => Smtp
lib/uri.rb  => Uri

This works, but in stdlib such names are defined as HTTP, SMTP and URI. This style guide also recommends keeping acronyms uppercase.

For example (form 2):

lib/h_t_t_p.rb => HTTP
lib/s_m_t_p.rb => SMTP
lib/u_r_i.rb   => URI

This also works, but the file names now look quite unusual.

What is the recommended way to deal with this?

Use form 1?
Use form 2?
Somehow combine form 1 (file name) with form 2 (class name)?

Thanks!

please include MIT-LICENSE

in the packaged gem:

$ ls zeitwerk-2.1.10
lib  README.md

Thanks!

zeitwerk (1.4.3) Rails 6 beta 3, killer bug

So I did bundle update and it went as usual, like a butter. Then I started rails server changed lot of things and took 20 trials to zero down to this gem. To reproduce, just change any controller or model or any rb file, no matter what the change is, even if there is no change (change-save undo-save), then the weird errors like constant User is undefined started popping out. Basically whole app code got lost. If you restart server it works again, until you make a first rb file related change, same again. Reverted to 1.4.2 to avoid this hell.

Zeitwerk 2.1.5 breaks: uninitialized constant

Zeitwerk 2.1.5 can raise an “uninitialized constant” error while 2.1.4 works fine.

Steps to reproduce

OK:

Clone https://github.com/ddfreyne/zeitwerk-nanoc-core-mini
Run bundle (this installs Zeitwerk 2.1.4)
Run bundle exec ruby test.rb

This prints

I am the thing! I exist!
Nanoc::Core::Thing

Let’s make it fail:

Change the zeitwerk line in Gemfile to gem 'zeitwerk', '= 2.1.5' (was = 2.1.4)
Run bundle
Run bundle exec ruby test.rb

This prints

`const_get': uninitialized constant NanocCore (NameError)

Expected results

Same behavior as Zeitwerk 2.1.4.

Actual results

Raises uninitialized constant NanocCore (NameError)

Extra details

Traceback:

Traceback (most recent call last):
	13: from test.rb:5:in `<main>'
	12: from test.rb:5:in `require'
	11: from /Users/denis/Desktop/zeitwerk-nanoc-core-mini/lib/nanoc-core.rb:3:in `<top (required)>'
	10: from /Users/denis/Desktop/zeitwerk-nanoc-core-mini/lib/nanoc-core.rb:3:in `require'
	 9: from /Users/denis/Desktop/zeitwerk-nanoc-core-mini/lib/nanoc/core.rb:20:in `<top (required)>'
	 8: from /usr/local/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.5/lib/zeitwerk/loader.rb:341:in `eager_load'
	 7: from /usr/local/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.5/lib/zeitwerk/loader.rb:341:in `synchronize'
	 6: from /usr/local/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.5/lib/zeitwerk/loader.rb:348:in `block in eager_load'
	 5: from /usr/local/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.5/lib/zeitwerk/loader.rb:631:in `each_abspath'
	 4: from /usr/local/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.5/lib/zeitwerk/loader.rb:631:in `foreach'
	 3: from /usr/local/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.5/lib/zeitwerk/loader.rb:634:in `block in each_abspath'
	 2: from /usr/local/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.5/lib/zeitwerk/loader.rb:352:in `block (2 levels) in eager_load'
	 1: from /usr/local/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.5/lib/zeitwerk/loader.rb:669:in `const_get_if_autoload'
/usr/local/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.5/lib/zeitwerk/loader.rb:669:in `const_get': uninitialized constant NanocCore (NameError)

It does not appear to be reloading the code on changes.

This issue is in reference to #19 (comment).

Adding code to a controller once the server has loaded does not get executed/updated.

Steps to reproduce:

rails new no-reload -d postgresql -m https://raw.githubusercontent.com/excid3/jumpstart/c6c0de0/template.rb
cd no-reload
foreman start
visit http://localhost:5000/users/sign_up
add the line after_action { pp 'foo' } to app/controllers/application_controller.rb
refresh the page
does not out put 'foo' to the console.

Expected outcome:

print foo to the console

Current work around:

add config.autoloader = :classic to config/application.rb

Screencast demonstrating issue:

https://cl.ly/577db63e745a

@fxn here is the Zeitwerk trace https://gist.github.com/cj/ffc8b578412034cebdd410bf534e4ab0

Better support for adapter pattern and optional source files in general (never eager load instead of ignore totally)

Background

Adapter is a popular design pattern in Ruby. Quite often, adapters rely on some optional dependencies, for example Active Record's SQLite3Adapter starts with following lines:

gem "sqlite3", "~> 1.3", ">= 1.3.6"
require "sqlite3"

(from rails/rails)

Consequently, adapter source file must be loaded conditionally, which isn't fully supported by Zeitwerk — not when a gem or application is supposed to be loaded eagerly. Zeitwerk's README explains how to workaround it:

On the other hand, if your code is eager loaded by you or a parent project (with Zeitwerk::Loader.eager_load_all), those require calls are going to be executed. Ignoring the adapters prevents that:
db_adapters = "#{__dir__}/my_gem/db_adapters"
loader.ignore(db_adapters)
loader.setup
The chosen adapter, then, has to be loaded by hand somehow:
require "my_gem/db_adapters/#{config[:db_adapter]}"

However, this basically means: do not use Zeitwerk for adapters at all. Switch back to old require instead, and resign from all the benefits Zeitwerk provides, including code reloading. I believe this could be improved.

Proposal

IMHO optional source files should be handled by Zeitwerk. The only thing what must be done in order to resolve this problem is to exclude them from being loaded eagerly. My proposal is to define a method Loader#exclude_from_eager_loading, which would work as in a following example:

db_adapters = "#{__dir__}/my_gem/db_adapters"
loader.exclude_from_eager_loading(db_adapters)
loader.setup

Then, given there is an adapter named MyGem::DbAdapters::MyAdapter defined in a source file my_gem/db_adapters/my_adapter.rb:

calling loader.eager_load would not load that source file;
referencing MyGem::DbAdapters::MyAdapter would load that source file, regardless if loader.eager_load has been called previously or not;
calling loader.preload("my_gem/db_adapters/my_adapter.rb") would also load that source file;

Also, perhaps it's worth to add an argument to #eager_load method, so that:

calling loader.eager_load(optional: true) would load that source file as well;

WDYT?

Are partially loaded classes visible?

Very interestingly looking project! I am curios, does the thread-safety property also guaranty that no other thread will see partially loaded class? Consider thread A, which triggers loading of a file defining class C. Then can a thread B which evaluates constant C while A is still lading the file defining C see the class C partially defined? As I read the code I think it might happen. Did you consider providing thread-safety for this as well?

Why does the project require ruby 2.4 and above? Are there technical difficulties to make it work with older Ruby versions?

-

please delete

Zeitwerk doesn't auto reload our code even with enable_reloading set to "true"

We're using Grape + ActiveRecord combo as our API service. Gems/Zeitwerk initializer looks like this:

# environment.rb

ENV['BUNDLE_GEMFILE'] ||= File.expand_path('../Gemfile', __FILE__)
ENV['RACK_ENV'] ||= 'development'

require 'bundler' and Bundler.require(:default, ENV['RACK_ENV'])
loader = Zeitwerk::Loader.new
%w(api models helpers lib).each { |dir| loader.push_dir(dir) }
loader.enable_reloading unless ENV['RACK_ENV'] == 'production'
loader.setup

later we call this code in our Rack app:

require_relative 'environment'

# mount Grape app, etc.

We want auto code reloading to work in development environment which is default in our setup. Current environment is defined by RACK_ENV env variable, no RAILS_ENV is used.

For some reason this setup doesn't work. Changes made to files in api, lib or other directories don't trigger code reloading. I believe there is no issue in Zeitwerk code, we're just missing something. Is it because of the absence of RAILS_ENV variable? We'd like to figure it out.

LoadError: cannot load such file

Hi,

I am trying to upgrade from Rails 6 beta 3 to finale but something changed.

My app uses this gem https://github.com/mickael-palma-argus/activestorage-openstack which also uses Zeitwerk (you helped me with it a few months back).

Everything worked fined with 6.0.0.beta3 but now when I start my app with the final 6.0.0 I have this error:

2019-08-23T10:05:47.295556+00:00 heroku[web.1]: Starting process with command `bundle exec puma -C config/puma.rb`
2019-08-23T10:05:49.585702+00:00 app[web.1]: Puma starting in single mode...
2019-08-23T10:05:49.585722+00:00 app[web.1]: * Version 4.1.0 (ruby 2.6.3-p62), codename: Fourth and One
2019-08-23T10:05:49.585724+00:00 app[web.1]: * Min threads: 20, max threads: 20
2019-08-23T10:05:49.585732+00:00 app[web.1]: * Environment: staging
2019-08-23T10:05:51.139101+00:00 heroku[web.1]: State changed from starting to crashed
2019-08-23T10:05:51.121376+00:00 heroku[web.1]: Process exited with status 1
2019-08-23T10:05:51.062382+00:00 app[web.1]: ! Unable to load application: NameError: expected file /usr/local/bundle/gems/activestorage_openstack-0.1.5/lib/active_storage/openstack/version.rb to define constant ActiveStorage::Openstack::Version, but didn't
2019-08-23T10:05:51.062493+00:00 app[web.1]: bundler: failed to load command: puma (/usr/local/bundle/bin/puma)
2019-08-23T10:05:51.062543+00:00 app[web.1]: NameError: expected file /usr/local/bundle/gems/activestorage_openstack-0.1.5/lib/active_storage/openstack/version.rb to define constant ActiveStorage::Openstack::Version, but didn't
2019-08-23T10:05:51.062545+00:00 app[web.1]: /usr/local/bundle/gems/zeitwerk-2.1.9/lib/zeitwerk/loader/callbacks.rb:17:in `on_file_autoloaded'
2019-08-23T10:05:51.062546+00:00 app[web.1]: /usr/local/bundle/gems/zeitwerk-2.1.9/lib/zeitwerk/kernel.rb:17:in `block in require'
2019-08-23T10:05:51.062548+00:00 app[web.1]: /usr/local/bundle/gems/zeitwerk-2.1.9/lib/zeitwerk/kernel.rb:16:in `tap'
2019-08-23T10:05:51.062549+00:00 app[web.1]: /usr/local/bundle/gems/zeitwerk-2.1.9/lib/zeitwerk/kernel.rb:16:in `require'
2019-08-23T10:05:51.062550+00:00 app[web.1]: /usr/local/bundle/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:351:in `const_get'
2019-08-23T10:05:51.062552+00:00 app[web.1]: /usr/local/bundle/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:351:in `block (2 levels) in eager_load'
2019-08-23T10:05:51.062553+00:00 app[web.1]: /usr/local/bundle/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:662:in `block in ls'
2019-08-23T10:05:51.062554+00:00 app[web.1]: /usr/local/bundle/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:659:in `foreach'
2019-08-23T10:05:51.062556+00:00 app[web.1]: /usr/local/bundle/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:659:in `ls'
2019-08-23T10:05:51.062557+00:00 app[web.1]: /usr/local/bundle/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:346:in `block in eager_load'
2019-08-23T10:05:51.062559+00:00 app[web.1]: /usr/local/bundle/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:338:in `synchronize'
2019-08-23T10:05:51.062560+00:00 app[web.1]: /usr/local/bundle/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:338:in `eager_load'
2019-08-23T10:05:51.062561+00:00 app[web.1]: /usr/local/bundle/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:449:in `each'
2019-08-23T10:05:51.062563+00:00 app[web.1]: /usr/local/bundle/gems/zeitwerk-2.1.9/lib/zeitwerk/loader.rb:449:in `eager_load_all'
2019-08-23T10:05:51.062564+00:00 app[web.1]: /usr/local/bundle/gems/railties-6.0.0/lib/rails/application/finisher.rb:122:in `block in <module:Finisher>'
2019-08-23T10:05:51.062565+00:00 app[web.1]: /usr/local/bundle/gems/railties-6.0.0/lib/rails/initializable.rb:32:in `instance_exec'
2019-08-23T10:05:51.062566+00:00 app[web.1]: /usr/local/bundle/gems/railties-6.0.0/lib/rails/initializable.rb:32:in `run'
2019-08-23T10:05:51.062568+00:00 app[web.1]: /usr/local/bundle/gems/railties-6.0.0/lib/rails/initializable.rb:61:in `block in run_initializers'
2019-08-23T10:05:51.062569+00:00 app[web.1]: /usr/local/lib/ruby/2.6.0/tsort.rb:228:in `block in tsort_each'
2019-08-23T10:05:51.062570+00:00 app[web.1]: /usr/local/lib/ruby/2.6.0/tsort.rb:350:in `block (2 levels) in each_strongly_connected_component'
2019-08-23T10:05:51.062571+00:00 app[web.1]: /usr/local/lib/ruby/2.6.0/tsort.rb:431:in `each_strongly_connected_component_from'
2019-08-23T10:05:51.062573+00:00 app[web.1]: /usr/local/lib/ruby/2.6.0/tsort.rb:349:in `block in each_strongly_connected_component'
2019-08-23T10:05:51.062574+00:00 app[web.1]: /usr/local/lib/ruby/2.6.0/tsort.rb:347:in `each'
2019-08-23T10:05:51.062575+00:00 app[web.1]: /usr/local/lib/ruby/2.6.0/tsort.rb:347:in `call'
2019-08-23T10:05:51.062577+00:00 app[web.1]: /usr/local/lib/ruby/2.6.0/tsort.rb:347:in `each_strongly_connected_component'
2019-08-23T10:05:51.062578+00:00 app[web.1]: /usr/local/lib/ruby/2.6.0/tsort.rb:226:in `tsort_each'
2019-08-23T10:05:51.062579+00:00 app[web.1]: /usr/local/lib/ruby/2.6.0/tsort.rb:205:in `tsort_each'
2019-08-23T10:05:51.062581+00:00 app[web.1]: /usr/local/bundle/gems/railties-6.0.0/lib/rails/initializable.rb:60:in `run_initializers'
2019-08-23T10:05:51.062582+00:00 app[web.1]: /usr/local/bundle/gems/railties-6.0.0/lib/rails/application.rb:363:in `initialize!'
2019-08-23T10:05:51.062583+00:00 app[web.1]: /app/config/environment.rb:7:in `<top (required)>'
2019-08-23T10:05:51.062585+00:00 app[web.1]: config.ru:5:in `require_relative'
2019-08-23T10:05:51.062586+00:00 app[web.1]: config.ru:5:in `block in <main>'
2019-08-23T10:05:51.062587+00:00 app[web.1]: /usr/local/bundle/gems/rack-2.0.7/lib/rack/builder.rb:55:in `instance_eval'
2019-08-23T10:05:51.062588+00:00 app[web.1]: /usr/local/bundle/gems/rack-2.0.7/lib/rack/builder.rb:55:in `initialize'
2019-08-23T10:05:51.062590+00:00 app[web.1]: config.ru:in `new'
2019-08-23T10:05:51.062591+00:00 app[web.1]: config.ru:in `<main>'
2019-08-23T10:05:51.062592+00:00 app[web.1]: /usr/local/bundle/gems/rack-2.0.7/lib/rack/builder.rb:49:in `eval'
2019-08-23T10:05:51.062594+00:00 app[web.1]: /usr/local/bundle/gems/rack-2.0.7/lib/rack/builder.rb:49:in `new_from_string'
2019-08-23T10:05:51.062595+00:00 app[web.1]: /usr/local/bundle/gems/rack-2.0.7/lib/rack/builder.rb:40:in `parse_file'
2019-08-23T10:05:51.062596+00:00 app[web.1]: /usr/local/bundle/gems/puma-4.1.0/lib/puma/configuration.rb:321:in `load_rackup'
2019-08-23T10:05:51.062598+00:00 app[web.1]: /usr/local/bundle/gems/puma-4.1.0/lib/puma/configuration.rb:246:in `app'
2019-08-23T10:05:51.062599+00:00 app[web.1]: /usr/local/bundle/gems/puma-4.1.0/lib/puma/runner.rb:148:in `load_and_bind'
2019-08-23T10:05:51.062600+00:00 app[web.1]: /usr/local/bundle/gems/puma-4.1.0/lib/puma/single.rb:98:in `run'
2019-08-23T10:05:51.062601+00:00 app[web.1]: /usr/local/bundle/gems/puma-4.1.0/lib/puma/launcher.rb:188:in `run'
2019-08-23T10:05:51.062603+00:00 app[web.1]: /usr/local/bundle/gems/puma-4.1.0/lib/puma/cli.rb:80:in `run'
2019-08-23T10:05:51.062604+00:00 app[web.1]: /usr/local/bundle/gems/puma-4.1.0/bin/puma:10:in `<top (required)>'
2019-08-23T10:05:51.062605+00:00 app[web.1]: /usr/local/bundle/bin/puma:23:in `load'
2019-08-23T10:05:51.062609+00:00 app[web.1]: /usr/local/bundle/bin/puma:23:in `<top (required)>'

Question on File Structure Best Practices

Hi, I have question regarding the best practices for file structure (ref)

In my Rails project, I organize lengthy constant declarations into separate files in order to keep classes clean.

For example:

# app/models/foo.rb
class Foo
end

# app/models/foo/constants.rb
class Foo
  MY_CONSTANT = ...
end

# elsewhere in app
Foo::MY_CONSTANT

However, Zeitwerk doesn't like this because it maps from filenames to constants, and requires those constants to be defined (ref). So, if you try to load the code above, you'll get an error message:

Excpeted file app/models/foo/constants.rb to define constant Foo::Constants, but didn't.

The obvious solution here is to define Foo::Constants:

# app/models/foo/constants.rb
class Foo
  module Constants
    MY_CONSTANT = ...
  end
end

# elsewhere in app
Foo::Constants::MY_CONSTANT

But, I have a lot of files like foo/constants.rb, and I am lazy. Are there any other alternatives for getting zeitwerk to autoload files like this?

I appreciate the work the team has done in this gem! It's a big improvement.

Zeitwerk will setup twice

reproduce steps (with ruby 2.6.1):

Gemfile:

source 'https://rubygems.org'
ruby '~> 2.6'
gem 'zeitwerk', '~> 2.1.2'

lib/foo.rb:

require 'zeitwerk'
loader = Zeitwerk::Loader.for_gem
loader.setup

module Foo; end

Run bundle exec ruby lib/foo.rb and get errors below:

Traceback (most recent call last):
        15: from lib/foo.rb:5:in `<main>'
        14: from /home/davy/.rvm/gems/ruby-2.6.1/gems/zeitwerk-2.1.2/lib/zeitwerk/kernel.rb:16:in `require'
        13: from /home/davy/.rvm/gems/ruby-2.6.1/gems/zeitwerk-2.1.2/lib/zeitwerk/kernel.rb:16:in `require'
        12: from /tmp/foo/lib/foo.rb:2:in `<top (required)>'
        11: from /home/davy/.rvm/gems/ruby-2.6.1/gems/zeitwerk-2.1.2/lib/zeitwerk/loader.rb:417:in `for_gem'
        10: from /home/davy/.rvm/gems/ruby-2.6.1/gems/zeitwerk-2.1.2/lib/zeitwerk/registry.rb:85:in `loader_for_gem'
         9: from /home/davy/.rvm/gems/ruby-2.6.1/gems/zeitwerk-2.1.2/lib/zeitwerk/registry.rb:85:in `tap'
         8: from /home/davy/.rvm/gems/ruby-2.6.1/gems/zeitwerk-2.1.2/lib/zeitwerk/registry.rb:88:in `block in loader_for_gem'
         7: from /home/davy/.rvm/gems/ruby-2.6.1/gems/zeitwerk-2.1.2/lib/zeitwerk/loader.rb:187:in `push_dir'
         6: from /home/davy/.rvm/gems/ruby-2.6.1/gems/zeitwerk-2.1.2/lib/zeitwerk/loader.rb:678:in `raise_if_conflicting_directory'
         5: from /home/davy/.rvm/gems/ruby-2.6.1/gems/zeitwerk-2.1.2/lib/zeitwerk/loader.rb:678:in `synchronize'
         4: from /home/davy/.rvm/gems/ruby-2.6.1/gems/zeitwerk-2.1.2/lib/zeitwerk/loader.rb:679:in `block in raise_if_conflicting_directory'
         3: from /home/davy/.rvm/gems/ruby-2.6.1/gems/zeitwerk-2.1.2/lib/zeitwerk/loader.rb:679:in `each'
         2: from /home/davy/.rvm/gems/ruby-2.6.1/gems/zeitwerk-2.1.2/lib/zeitwerk/loader.rb:682:in `block (2 levels) in raise_if_conflicting_directory'
         1: from /home/davy/.rvm/gems/ruby-2.6.1/gems/zeitwerk-2.1.2/lib/zeitwerk/loader.rb:682:in `each'
/home/davy/.rvm/gems/ruby-2.6.1/gems/zeitwerk-2.1.2/lib/zeitwerk/loader.rb:685:in `block (3 levels) in raise_if_conflicting_directory': loader (Zeitwerk::Error)

#<Zeitwerk::Loader:0x00000000021473d0
 @autoloaded_dirs=[],
 @autoloads={},
 @eager_load_exclusions=#<Set: {}>,
 @eager_loaded=false,
 @ignored=#<Set: {}>,
 @ignored_paths=#<Set: {}>,
 @inflector=
  #<Zeitwerk::GemInflector:0x0000000002158860
   @version_file=
    "/tmp/foo/lib/foo/version.rb">,
 @initialized_at=2019-04-15 16:40:21 +0800,
 @lazy_subdirs={},
 @logger=nil,
 @mutex=#<Thread::Mutex:0x0000000002144158>,
 @mutex2=#<Thread::Mutex:0x0000000002144108>,
 @preloads=[],
 @reloading_enabled=false,
 @root_dirs={},
 @setup=false,
 @shadowed_files=#<Set: {}>,
 @tag="foo",
 @to_unload={}>


wants to manage directory /tmp/foo/lib, which is already managed by

#<Zeitwerk::Loader:0x0000000002155e80
 @autoloaded_dirs=[],
 @autoloads=
  {"/tmp/foo/lib/foo.rb"=>[Object, "Foo"]},
 @eager_load_exclusions=#<Set: {}>,
 @eager_loaded=false,
 @ignored=#<Set: {}>,
 @ignored_paths=#<Set: {}>,
 @inflector=
  #<Zeitwerk::GemInflector:0x000000000217b978
   @version_file="lib/foo/version.rb">,
 @initialized_at=2019-04-15 16:40:21 +0800,
 @lazy_subdirs={},
 @logger=nil,
 @mutex=#<Thread::Mutex:0x0000000002154c38>,
 @mutex2=#<Thread::Mutex:0x0000000002154b48>,
 @preloads=[],
 @reloading_enabled=false,
 @root_dirs={"/tmp/foo/lib"=>true},
 @setup=true,
 @shadowed_files=#<Set: {}>,
 @tag="foo",
 @to_unload={}>

It seems lib/foo.rb loaded again when loader.setup called and caused another loader setups, and this caused crashes

	# lib/my_gem.rb (main file)

	require "zeitwerk"
	loader = Zeitwerk::Loader.for_gem
	loader.setup # ready!

	module MyGem
	# ...
	end

	loader.eager_load # optionally

fxn / zeitwerk Goto Github PK

zeitwerk's People

Contributors

Stargazers

Watchers

Forkers

zeitwerk's Issues

Steps to reproduce

folder directory:

content of config.ru

content of app.rb

content of Gemfile

start up server

first time visit http://127.0.0.1:9292/ in browser

change code from 'hello1' to 'hello2' in app.rb, visit http://127.0.0.1:9292/ again

expected behavior

actually behavior

Steps to reproduce:

Step 1:

Step 2:

Step 3:

Step 4:

Steps to reproduce

folder directory:

content of config.ru

content of app.rb

start server, and post http://127.0.0.1:9292/articles?content='content' repeatly.

Expected behavior

Actual behavior

Steps to reproduce

Expected results

Actual results

Extra details

Steps to reproduce:

Expected outcome:

Current work around:

Screencast demonstrating issue:

Background

Proposal

Recommend Projects

Recommend Topics

Recommend Org

Jobs