zeitwerk 2.3.0 → 2.4.0

Sign up to get free protection for your applications and to get access to all the features.
checksums.yaml CHANGED
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  SHA256:
3
- metadata.gz: b8fd1828e8e92937af8b1e46033442f517c65c07a443a9a265b67c03f22b8b86
4
- data.tar.gz: 4e04076d6ac82d1bff9bf3db8604ca7e826afad753fb1268116cd115f15d301b
3
+ metadata.gz: 682fa352a9d6d4bf68d07cf2cbfbb539de3cfec4e8af2f930894ab27c707ca93
4
+ data.tar.gz: 1e7ce6157e6046cdb60f0f1b531f1f39fb97cad3537392114be5cf84dae672c9
5
5
  SHA512:
6
- metadata.gz: cacd0d2c43a566a5e3be7dfb98585e9598a9fda8e930bb0f97a96180db332d6303fb1cfbf850f85dd822071968fc624262b94c27db85ad3e1236f1e243df64c2
7
- data.tar.gz: 0f9c90d543eae10edade4777f63c02a0f5ef30ecfdfe752fc9f11e5f6e3c835d2b893b0e8074e4cd068859e41dcf6e5374527c73499876deab3a9974cd0d2bf4
6
+ metadata.gz: e308baba1a8fbe4d7c64d7195c753d795a53caefa7264d2404117cb620f2081f6b0fc05c056dafb035b44430102e4472b7eb9fb3a4fd9d70aa124b7f9a3a8313
7
+ data.tar.gz: 5139d5abaeed86e256493b592460b13b19fd7602f7c099f7017b55af9f16a91429e84074a4e31fe79bf28235e02cbba3055cc4bda579bbc7de2a391c5997a393
data/README.md CHANGED
@@ -16,6 +16,8 @@
16
16
  - [Nested root directories](#nested-root-directories)
17
17
  - [Usage](#usage)
18
18
  - [Setup](#setup)
19
+ - [Generic](#generic)
20
+ - [for_gem](#for_gem)
19
21
  - [Autoloading](#autoloading)
20
22
  - [Eager loading](#eager-loading)
21
23
  - [Reloading](#reloading)
@@ -30,8 +32,11 @@
30
32
  - [Use case: The adapter pattern](#use-case-the-adapter-pattern)
31
33
  - [Use case: Test files mixed with implementation files](#use-case-test-files-mixed-with-implementation-files)
32
34
  - [Edge cases](#edge-cases)
35
+ - [Reopening third-party namespaces](#reopening-third-party-namespaces)
33
36
  - [Rules of thumb](#rules-of-thumb)
34
- - [Autoloading, explicit namespaces, and debuggers](#autoloading-explicit-namespaces-and-debuggers)
37
+ - [Debuggers](#debuggers)
38
+ - [Break](#break)
39
+ - [Byebug](#byebug)
35
40
  - [Pronunciation](#pronunciation)
36
41
  - [Supported Ruby versions](#supported-ruby-versions)
37
42
  - [Testing](#testing)
@@ -52,7 +57,9 @@ Zeitwerk is also able to reload code, which may be handy while developing web ap
52
57
 
53
58
  The gem is designed so that any project, gem dependency, application, etc. can have their own independent loader, coexisting in the same process, managing their own project trees, and independent of each other. Each loader has its own configuration, inflector, and optional logger.
54
59
 
55
- Internally, Zeitwerk issues `require` calls exclusively using absolute file names, so there are no costly file system lookups in `$LOAD_PATH`. Technically, the directories managed by Zeitwerk do not even need to be in `$LOAD_PATH`. Furthermore, Zeitwerk does only one single scan of the project tree, and it descends into subdirectories lazily, only if their namespaces are used.
60
+ Internally, Zeitwerk issues `require` calls exclusively using absolute file names, so there are no costly file system lookups in `$LOAD_PATH`. Technically, the directories managed by Zeitwerk do not even need to be in `$LOAD_PATH`.
61
+
62
+ Furthermore, Zeitwerk does at most one single scan of the project tree, and it descends into subdirectories lazily, only if their namespaces are used.
56
63
 
57
64
  <a id="markdown-synopsis" name="synopsis"></a>
58
65
  ## Synopsis
@@ -132,6 +139,22 @@ app/models/user.rb -> User
132
139
  app/controllers/admin/users_controller.rb -> Admin::UsersController
133
140
  ```
134
141
 
142
+ Alternatively, you can associate a custom namespace to a root directory by passing a class or module object in the optional `namespace` keyword argument.
143
+
144
+ For example, Active Job queue adapters have to define a constant after their name in `ActiveJob::QueueAdapters`.
145
+
146
+ So, if you declare
147
+
148
+ ```ruby
149
+ require "active_job"
150
+ require "active_job/queue_adapters"
151
+ loader.push_dir("#{__dir__}/adapters", namespace: ActiveJob::QueueAdapters)
152
+ ```
153
+
154
+ your adapter can be stored directly in that directory instead of the canonical `lib/active_job/queue_adapters`.
155
+
156
+ Please, note that the given namespace must be non-reloadable, though autoloaded constants in that namespace can be. That is, if you associate `app/api` with an existing `Api` module, that module should not be reloadable. However, if the project defines and autoloads the class `Api::V2::Deliveries`, that one can be reloaded.
157
+
135
158
  <a id="markdown-implicit-namespaces" name="implicit-namespaces"></a>
136
159
  ### Implicit namespaces
137
160
 
@@ -211,6 +234,9 @@ should define `Geolocatable`, not `Concerns::Geolocatable`.
211
234
  <a id="markdown-setup" name="setup"></a>
212
235
  ### Setup
213
236
 
237
+ <a id="markdown-generic" name="generic"></a>
238
+ #### Generic
239
+
214
240
  Loaders are ready to load code right after calling `setup` on them:
215
241
 
216
242
  ```ruby
@@ -227,9 +253,36 @@ loader.push_dir(...)
227
253
  loader.setup
228
254
  ```
229
255
 
230
- The loader returned by `Zeitwerk::Loader.for_gem` has the directory of the caller pushed, normally that is the absolute path of `lib`. In that sense, `for_gem` can be used also by projects with a gem structure, even if they are not technically gems. That is, you don't need a gemspec or anything.
256
+ <a id="markdown-for_gem" name="for_gem"></a>
257
+ #### for_gem
258
+
259
+ `Zeitwerk::Loader.for_gem` is a convenience shortcut for the common case in which a gem has its entry point directly under the `lib` directory:
260
+
261
+ ```
262
+ lib/my_gem.rb # MyGem
263
+ lib/my_gem/version.rb # MyGem::VERSION
264
+ lib/my_gem/foo.rb # MyGem::Foo
265
+ ```
266
+
267
+ Neither a gemspec nor a version file are technically required, this helper works as long as the code is organized using that standard structure.
231
268
 
232
- If the main module of a library references project constants at the top-level, Zeitwerk has to be ready to load them. Their definitions, in turn, may reference other project constants. And this is recursive. Therefore, it is important that the `setup` call happens above the main module definition:
269
+ If the entry point of your gem lives in a subdirectory of `lib` because it is reopening a namespace defined somewhere else, please use the generic API to setup the loader, and make sure you check the section [_Reopening third-party namespaces_](https://github.com/fxn/zeitwerk#reopening-third-party-namespaces) down below.
270
+
271
+ Conceptually, `for_gem` translates to:
272
+
273
+ ```ruby
274
+ # lib/my_gem.rb
275
+
276
+ require "zeitwerk"
277
+ loader = Zeitwerk::Loader.new
278
+ loader.tag = File.basename(__FILE__, ".rb")
279
+ loader.inflector = Zeitwerk::GemInflector.new(__FILE__)
280
+ loader.push_dir(__dir__)
281
+ ```
282
+
283
+ except that this method returns the same object in subsequent calls from the same file, in the unlikely case the gem wants to be able to reload.
284
+
285
+ If the main module references project constants at the top-level, Zeitwerk has to be ready to load them. Their definitions, in turn, may reference other project constants. And this is recursive. Therefore, it is important that the `setup` call happens above the main module definition:
233
286
 
234
287
  ```ruby
235
288
  # lib/my_gem.rb (main file)
@@ -245,8 +298,6 @@ module MyGem
245
298
  end
246
299
  ```
247
300
 
248
- Zeitwerk works internally only with absolute paths to avoid costly file searches in `$LOAD_PATH`. Indeed, the root directories do not even need to belong to `$LOAD_PATH`, everything just works by design if they don't.
249
-
250
301
  <a id="markdown-autoloading" name="autoloading"></a>
251
302
  ### Autoloading
252
303
 
@@ -619,6 +670,42 @@ Trip = Struct.new { ... } # NOT SUPPORTED
619
670
 
620
671
  This only affects explicit namespaces, those idioms work well for any other ordinary class or module.
621
672
 
673
+ <a id="markdown-reopening-third-party-namespaces" name="reopening-third-party-namespaces"></a>
674
+ ### Reopening third-party namespaces
675
+
676
+ Projects managed by Zeitwerk can work with namespaces defined by third-party libraries. However, they have to be loaded in memory before calling `setup`.
677
+
678
+ For example, let's imagine you're writing a gem that implements an adapter for [Active Job](https://guides.rubyonrails.org/active_job_basics.html) that uses AwesomeQueue as backend. By convention, your gem has to define a class called `ActiveJob::QueueAdapters::AwesomeQueue`, and it has to do so in a file with a matching path:
679
+
680
+ ```ruby
681
+ # lib/active_job/queue_adapters/awesome_queue.rb
682
+ module ActiveJob
683
+ module QueueAdapters
684
+ class AwesomeQueue
685
+ # ...
686
+ end
687
+ end
688
+ end
689
+ ```
690
+
691
+ It is very important that your gem _reopens_ the modules `ActiveJob` and `ActiveJob::QueueAdapters` instead of _defining_ them. Because their proper definition lives in Active Job. Furthermore, if the project reloads, you do not want any of `ActiveJob` or `ActiveJob::QueueAdapters` to be reloaded.
692
+
693
+ Bottom line, Zeitwerk should not be managing those namespaces. Active Job owns them and defines them. Your gem needs to _reopen_ them.
694
+
695
+ In order to do so, you need to make sure those modules are loaded before calling `setup`. For instance, in the entry file for the gem:
696
+
697
+ ```ruby
698
+ # Ensure these namespaces are reopened, not defined.
699
+ require "active_job"
700
+ require "active_job/queue_adapters"
701
+
702
+ require "zeitwerk"
703
+ loader = Zeitwerk::Loader.for_gem
704
+ loader.setup
705
+ ```
706
+
707
+ With that, when Zeitwerk scans the file system and reaches the gem directories `lib/active_job` and `lib/active_job/queue_adapters`, it detects the corresponding modules already exist and therefore understands it does not have to manage them. The loader just descends into those directories. Eventually will reach `lib/active_job/queue_adapters/awesome_queue.rb`, and since `ActiveJob::QueueAdapters::AwesomeQueue` is unknown, Zeitwerk will manage it. Which is what happens regularly with the files in your gem. On reload, the namespaces are safe, won't be reloaded. The loader only reloads what it manages, which in this case is the adapter itself.
708
+
622
709
  <a id="markdown-rules-of-thumb" name="rules-of-thumb"></a>
623
710
  ### Rules of thumb
624
711
 
@@ -634,14 +721,18 @@ This only affects explicit namespaces, those idioms work well for any other ordi
634
721
 
635
722
  6. In a given process, ideally, there should be at most one loader with reloading enabled. Technically, you can have more, but it may get tricky if one refers to constants managed by the other one. Do that only if you know what you are doing.
636
723
 
637
- <a id="markdown-autoloading-explicit-namespaces-and-debuggers" name="autoloading-explicit-namespaces-and-debuggers"></a>
638
- ### Autoloading, explicit namespaces, and debuggers
724
+ <a id="markdown-debuggers" name="debuggers"></a>
725
+ ### Debuggers
726
+
727
+ <a id="markdown-break" name="break"></a>
728
+ #### Break
639
729
 
640
- As of this writing, Zeitwerk is unable to autoload classes or modules that belong to [explicit namespaces](#explicit-namespaces) inside debugger sessions. You'll get a `NameError`.
730
+ Zeitwerk works fine with [@gsamokovarov](https://github.com/gsamokovarov)'s [Break](https://github.com/gsamokovarov/break) debugger.
641
731
 
642
- The root cause is that debuggers set trace points, and Zeitwerk does too to support explicit namespaces. A debugger session happens inside a trace point handler, and Ruby does not invoke other handlers from within a running handler. Therefore, the code that manages explicit namespaces in Zeitwerk does not get called by the interpreter. See [this issue](https://github.com/deivid-rodriguez/byebug/issues/564#issuecomment-499413606) for further details.
732
+ <a id="markdown-byebug" name="byebug"></a>
733
+ #### Byebug
643
734
 
644
- As a workaround, you can eager load. Zeitwerk tries hard to succeed or fail consistently both autoloading and eager loading, so switching to eager loading should not introduce any interference in your debugging logic, generally speaking.
735
+ Zeitwerk and [Byebug](https://github.com/deivid-rodriguez/byebug) are incompatible, classes or modules that belong to [explicit namespaces](#explicit-namespaces) are not autoloaded inside a Byebug session. See [this issue](https://github.com/deivid-rodriguez/byebug/issues/564#issuecomment-499413606) for further details.
645
736
 
646
737
  <a id="markdown-pronunciation" name="pronunciation"></a>
647
738
  ## Pronunciation
@@ -15,7 +15,7 @@ module Zeitwerk
15
15
  # @param _abspath [String]
16
16
  # @return [String]
17
17
  def camelize(basename, _abspath)
18
- overrides[basename] || basename.split('_').map!(&:capitalize).join
18
+ overrides[basename] || basename.split('_').each(&:capitalize!).join
19
19
  end
20
20
 
21
21
  # Configures hard-coded inflections:
@@ -3,6 +3,17 @@
3
3
  module Kernel
4
4
  module_function
5
5
 
6
+ # We are going to decorate Kerner#require with two goals.
7
+ #
8
+ # First, by intercepting Kernel#require calls, we are able to autovivify
9
+ # modules on required directories, and also do internal housekeeping when
10
+ # managed files are loaded.
11
+ #
12
+ # On the other hand, if you publish a new version of a gem that is now managed
13
+ # by Zeitwerk, client code can reference directly your classes and modules and
14
+ # should not require anything. But if someone has legacy require calls around,
15
+ # they will work as expected, and in a compatible way.
16
+ #
6
17
  # We cannot decorate with prepend + super because Kernel has already been
7
18
  # included in Object, and changes in ancestors don't get propagated into
8
19
  # already existing ancestor chains.
@@ -30,4 +41,24 @@ module Kernel
30
41
  end
31
42
  end
32
43
  end
44
+
45
+ # By now, I have seen no way so far to decorate require_relative.
46
+ #
47
+ # For starters, at least in CRuby, require_relative does not delegate to
48
+ # require. Both require and require_relative delegate the bulk of their work
49
+ # to an internal C function called rb_require_safe. So, our require wrapper is
50
+ # not executed.
51
+ #
52
+ # On the other hand, we cannot use the aliasing technique above because
53
+ # require_relative receives a path relative to the directory of the file in
54
+ # which the call is performed. If a wrapper here invoked the original method,
55
+ # Ruby would resolve the relative path taking lib/zeitwerk as base directory.
56
+ #
57
+ # A workaround could be to extract the base directory from caller_locations,
58
+ # but what if someone else decorated require_relative before us? You can't
59
+ # really know with certainty where's the original call site in the stack.
60
+ #
61
+ # However, the main use case for require_relative is to load files from your
62
+ # own project. Projects managed by Zeitwerk don't do this for files managed by
63
+ # Zeitwerk, precisely.
33
64
  end
@@ -190,13 +190,19 @@ module Zeitwerk
190
190
  # or descendants.
191
191
  #
192
192
  # @param path [<String, Pathname>]
193
+ # @param namespace [Class, Module]
193
194
  # @raise [Zeitwerk::Error]
194
195
  # @return [void]
195
- def push_dir(path)
196
+ def push_dir(path, namespace: Object)
197
+ # Note that Class < Module.
198
+ unless namespace.is_a?(Module)
199
+ raise Error, "#{namespace.inspect} is not a class or module object, should be"
200
+ end
201
+
196
202
  abspath = File.expand_path(path)
197
203
  if dir?(abspath)
198
204
  raise_if_conflicting_directory(abspath)
199
- root_dirs[abspath] = true
205
+ root_dirs[abspath] = namespace
200
206
  else
201
207
  raise Error, "the root directory #{abspath} does not exist"
202
208
  end
@@ -268,7 +274,9 @@ module Zeitwerk
268
274
  mutex.synchronize do
269
275
  break if @setup
270
276
 
271
- actual_root_dirs.each { |root_dir| set_autoloads_in_dir(root_dir, Object) }
277
+ actual_root_dirs.each do |root_dir, namespace|
278
+ set_autoloads_in_dir(root_dir, namespace)
279
+ end
272
280
  do_preload
273
281
 
274
282
  @setup = true
@@ -368,8 +376,11 @@ module Zeitwerk
368
376
  mutex.synchronize do
369
377
  break if @eager_loaded
370
378
 
371
- queue = actual_root_dirs.reject { |dir| eager_load_exclusions.member?(dir) }
372
- queue.map! { |dir| [Object, dir] }
379
+ queue = []
380
+ actual_root_dirs.each do |root_dir, namespace|
381
+ queue << [namespace, root_dir] unless eager_load_exclusions.member?(root_dir)
382
+ end
383
+
373
384
  while to_eager_load = queue.shift
374
385
  namespace, dir = to_eager_load
375
386
 
@@ -464,7 +475,7 @@ module Zeitwerk
464
475
  # require "zeitwerk"
465
476
  # loader = Zeitwerk::Loader.new
466
477
  # loader.tag = File.basename(__FILE__, ".rb")
467
- # loader.inflector = Zeitwerk::GemInflector.new
478
+ # loader.inflector = Zeitwerk::GemInflector.new(__FILE__)
468
479
  # loader.push_dir(__dir__)
469
480
  #
470
481
  # except that this method returns the same object in subsequent calls from
@@ -498,7 +509,7 @@ module Zeitwerk
498
509
 
499
510
  # @return [<String>]
500
511
  def actual_root_dirs
501
- root_dirs.keys.delete_if do |root_dir|
512
+ root_dirs.reject do |root_dir, _namespace|
502
513
  !dir?(root_dir) || ignored_paths.member?(root_dir)
503
514
  end
504
515
  end
@@ -616,7 +627,10 @@ module Zeitwerk
616
627
  # $LOADED_FEATURES stores real paths since Ruby 2.4.4. We set and save the
617
628
  # real path to be able to delete it from $LOADED_FEATURES on unload, and to
618
629
  # be able to do a lookup later in Kernel#require for manual require calls.
619
- realpath = File.realpath(abspath)
630
+ #
631
+ # We freeze realpath because that saves allocations in Module#autoload.
632
+ # See #125.
633
+ realpath = File.realpath(abspath).freeze
620
634
  parent.autoload(cname, realpath)
621
635
  if logger
622
636
  if ruby?(realpath)
@@ -719,8 +733,13 @@ module Zeitwerk
719
733
  def ls(dir)
720
734
  Dir.foreach(dir) do |basename|
721
735
  next if basename.start_with?(".")
736
+
722
737
  abspath = File.join(dir, basename)
723
- yield basename, abspath unless ignored_paths.member?(abspath)
738
+ next if ignored_paths.member?(abspath)
739
+
740
+ # We freeze abspath because that saves allocations when passed later to
741
+ # File methods. See #125.
742
+ yield basename, abspath.freeze
724
743
  end
725
744
  end
726
745
 
@@ -1,5 +1,5 @@
1
1
  # frozen_string_literal: true
2
2
 
3
3
  module Zeitwerk
4
- VERSION = "2.3.0"
4
+ VERSION = "2.4.0"
5
5
  end
metadata CHANGED
@@ -1,19 +1,19 @@
1
1
  --- !ruby/object:Gem::Specification
2
2
  name: zeitwerk
3
3
  version: !ruby/object:Gem::Version
4
- version: 2.3.0
4
+ version: 2.4.0
5
5
  platform: ruby
6
6
  authors:
7
7
  - Xavier Noria
8
8
  autorequire:
9
9
  bindir: bin
10
10
  cert_chain: []
11
- date: 2020-03-03 00:00:00.000000000 Z
11
+ date: 2020-07-14 00:00:00.000000000 Z
12
12
  dependencies: []
13
13
  description: |2
14
14
  Zeitwerk implements constant autoloading with Ruby semantics. Each gem
15
15
  and application may have their own independent autoloader, with its own
16
- configuration, inflector, and logger. Supports autoloading, preloading,
16
+ configuration, inflector, and logger. Supports autoloading,
17
17
  reloading, and eager loading.
18
18
  email: fxn@hashref.com
19
19
  executables: []
@@ -36,7 +36,11 @@ files:
36
36
  homepage: https://github.com/fxn/zeitwerk
37
37
  licenses:
38
38
  - MIT
39
- metadata: {}
39
+ metadata:
40
+ homepage_uri: https://github.com/fxn/zeitwerk
41
+ changelog_uri: https://github.com/fxn/zeitwerk/blob/master/CHANGELOG.md
42
+ source_code_uri: https://github.com/fxn/zeitwerk
43
+ bug_tracker_uri: https://github.com/fxn/zeitwerk/issues
40
44
  post_install_message:
41
45
  rdoc_options: []
42
46
  require_paths:
@@ -52,7 +56,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
52
56
  - !ruby/object:Gem::Version
53
57
  version: '0'
54
58
  requirements: []
55
- rubygems_version: 3.0.3
59
+ rubygems_version: 3.1.2
56
60
  signing_key:
57
61
  specification_version: 4
58
62
  summary: Efficient and thread-safe constant autoloader