zeitwerk | Efficient and thread-safe code loader for Ruby

by fxn Ruby Version: v2.6.8 License: MIT

X-Ray Key Features Code Snippets Community Discussions(10)Vulnerabilities Install Support

kandi X-RAY | zeitwerk Summary

zeitwerk is a Ruby library. zeitwerk has no bugs, it has no vulnerabilities, it has a Permissive License and it has medium support. You can download it from GitHub.

Zeitwerk is an efficient and thread-safe code loader for Ruby. Given a conventional file structure, Zeitwerk is able to load your project's classes and modules on demand (autoloading), or upfront (eager loading). You don't need to write require calls for your own files, rather, you can streamline your programming knowing that your classes and modules are available everywhere. This feature is efficient, thread-safe, and matches Ruby's semantics for constants. Zeitwerk is also able to reload code, which may be handy while developing web applications. Coordination is needed to reload in a thread-safe manner. The documentation below explains how to do this. 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. 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 at most one single scan of the project tree, and it descends into subdirectories lazily, only if their namespaces are used.

Support

Quality

Security

License

Reuse

Support

zeitwerk has a medium active ecosystem.

It has 1762 star(s) with 115 fork(s). There are 24 watchers for this library.

It had no major release in the last 6 months.

There are 0 open issues and 182 have been closed. On average issues are closed in 3 days. There are no pull requests.

It has a neutral sentiment in the developer community.

The latest version of zeitwerk is v2.6.8

Quality

zeitwerk has 0 bugs and 0 code smells.

Security

zeitwerk has no vulnerabilities reported, and its dependent libraries have no vulnerabilities reported.

zeitwerk code analysis shows 0 unresolved vulnerabilities.

There are 0 security hotspots that need review.

License

zeitwerk is licensed under the MIT License. This license is Permissive.

Permissive licenses have the least restrictions, and you can use them in most projects.

Reuse

zeitwerk releases are not available. You will need to build from source code and install.

Installation instructions, examples and code snippets are available.

It has 4009 lines of code, 141 functions and 53 files.

It has low code complexity. Code complexity directly impacts maintainability of the code.

Top functions reviewed by kandi - BETA

kandi's functional review helps you automatically verify the functionalities of the libraries and avoid rework.
Currently covering the most popular Java, JavaScript and Python libraries. See a Sample of zeitwerk

Get all kandi verified functions for this library.

zeitwerk Key Features

No Key Features are available at this moment for zeitwerk.

zeitwerk Examples and Code Snippets

No Code Snippets are available at this moment for zeitwerk.

Community Discussions

Trending Discussions on zeitwerk

Rails 7 controller decorator uninitialised constant error in production only

Zeitwerk needs to reload every change

Rails 6 + Zeitwerk, loading files without class

visit_Psych_Nodes_Alias: Unknown alias: default (Psych::BadAlias)

rails 7 zietwerk constants not found

uninitialized constant when reloading after enabling zeitwerk

Rails - uninitialized constant error by Puma when trying to start the server (WIndows 11)

Rails 7 Autoloading problem with active job

ElasticSearch deployment issue: NameError: uninitialized constant Elasticsearch

Rails Zeitwerk snakecase

QUESTION

Rails 7 controller decorator uninitialised constant error in production only

Asked 2022-Apr-03 at 17:27

I am getting the following error zeitwerk/loader/helpers.rb:95:in const_get': uninitialized constant Controllers::BasePublicDecorator (NameError) This is an error in a local production console using rails c -e production but not an issue in development which works perfectly.

In an engine, CcsCms::PublicTheme, I have a decorator I am using to extend the controller of another CcsCms::Core engine and it is this decorator that is causing the error.

public_theme/app/decorators/decorators/controllers/base_public_decorator.rb

...

ANSWER

Answered 2022-Apr-02 at 19:30

Problem here is that when lazy loading, nobody is referencing a constant called ...::BasePublicDecorator. However, Zeitwerk expects that constant to be defined in that file, and the mismatch is found when eager loading.

The solution is to configure the autoloader to ignore the decorators, because you are handling their loading, and because they do not define constants after their names. This documentation has an example. It needs to be adapted to your engine, but you'll see the idea.

For completeness, let me also explain that in Zeitwerk, eager loading is a recursive const_get, not a recursive require. This is to guarantee that if you access the constant, loading succeeds or fails consistently in both modes (and it is also a tad more efficient). Recursive const_get still issues require calls via Module#autoload, and if you ran one for some file idempotence also applies, but Zeitwerk detects the expected constant is not defined anyway, which is an error condition.

Source https://stackoverflow.com/questions/71719652

QUESTION

Zeitwerk needs to reload every change

Asked 2022-Mar-29 at 22:04

In development enviroment, when using zeitwerk, every change in ruby code needs to restart the server, because zeitwerk isn't loading classes defined in mygem. I have a gem, used by my company that uses rails models. And some of that models are reopened, and we add some methods.

I have the following model in my app.

...

ANSWER

Answered 2022-Mar-29 at 22:04

You cannot have two files defining the same constant in the autoload paths.

Your engine defines a model, and the application wants to decorate it. For this use case, please have a look at this documentation.

Source https://stackoverflow.com/questions/71668387

QUESTION

Rails 6 + Zeitwerk, loading files without class

Asked 2022-Mar-22 at 15:18

We are upgrading to Rails 6, and have done most of the work to make our application work with Zeitwerk.

We do have two files, which are query objects, existing under app/queries and we don't define a class for them. They exists with methods only.

However, Zeitwerk expects the file to define a constant, but we don't deem it necessary.

Is there any way to tell Zeitwerk that we want to load these files as is?

...

ANSWER

Answered 2022-Mar-22 at 15:18

You can tell the main autoloader to ignore them:

Source https://stackoverflow.com/questions/71571564

QUESTION

visit_Psych_Nodes_Alias: Unknown alias: default (Psych::BadAlias)

Asked 2022-Mar-19 at 10:21

I updated from ruby 2.7.1 to 3.1.1, then removed Gemfile.lock and ran bundle update (it's on a dev branch, so I can throw it away if this is a bad idea, I just wanted to see if it would work).

bundle update succeeds, but when I start the server:

...

ANSWER

Answered 2022-Mar-19 at 10:21

The problem is related to the Ruby 3.1 / Psych 4.x incompatibility described in this issue: https://bugs.ruby-lang.org/issues/17866

Ruby 3.0 comes with Psych 3, while Ruby 3.1 comes with Psych 4, which has a major breaking change (diff 3.3.2 → 4.0.0).

The new YAML loading methods (Psych 4) do not load aliases unless they get the aliases: true argument.
The old YAML loading methods (Psych 3) do not support the aliases keyword.

At this point, it seems like anyone, anywhere that wants to load YAML in the same way it worked prior to Ruby 3.1, need to do something like this:

Source https://stackoverflow.com/questions/71191685

QUESTION

rails 7 zietwerk constants not found

Asked 2022-Mar-08 at 03:53

I'm upgrading our app from rails 6 to 7, I was using zeitwerk instead of the classic autoloader with rails 6 without any issues, now without any changes to the folder/file naming convention or structure it fails to find any classes/modules inside lib folder. I've been debugging the zeitwerk gem and the autoloads hash has file paths as keys and [Namespace, Constant Name] as the value, with rails 6 it had correct name space, e.g. for a file in \user\project\rails6_test\lib\folder\config.rb it'd have Folder as the namespace and Config defined inside config.rb would be found correctly in Folder namespace but after the migration with rails 7 it always has Object as the namespace, not just for top level folders but for all nested files and obviously it can't find those constants in the Object.

I don't see anything that I missed from the upgrade guide, what could be missing here ?

Update

I tried running bin/rails r 'pp ActiveSupport::Dependencies.autoload_paths' and I get the error below,

...

ANSWER

Answered 2022-Mar-05 at 22:51

Thanks for the updates. The problem is this glob:

Source https://stackoverflow.com/questions/71318387

QUESTION

uninitialized constant when reloading after enabling zeitwerk

Asked 2022-Mar-05 at 23:00

Having some trouble working out the migration from Classic to Zeitwerk.

After enabling zeitwerk and running rails s, everything seems to work. Then after saving a .rb file and refreshing, I'm seeing an "uninitialized constant" error when trying to require a file from the top level /lib.

Something is misconfigured w/ reloading, but I'm scratching my head trying to work out the details. I was under the impression that having a top level /lib folder is fine and using require to load files in that directory is compatible with Zeitwerk, but now I'm not so sure... ideas as to what I'm getting wrong?

Note: I'm not currently setting any specific eager_load_paths or autoload_paths

EDIT: updated with logging output as suggested by @Xavier

...

ANSWER

Answered 2022-Mar-05 at 23:00

The namespace CustomModule is shared in parts of the project that are reloadable (under app), and also in parts where is not (under lib).

This is fine, it is supported. You only need to deliberately think about load priorities, because if lib defines CustomModule::Foo and Rails believes CustomModule is reloadable, on reload nobody is loading CustomModule::Foo again, and require is idempotent, so CustomModule::Foo won't be found anymore.

The solution is to make sure lib defines the namespace, and Rails autoloaders reopen it. Essentially same as documented here. This can be done by issuing a require in an initializer that loads the namespace from lib, for example.

That way, when the autoloader scans the file system, it knows it is not responsible for managing CustomModule. It will descend. If there are child constants there everything will work as usual, and those constants will be reloaded, but the namespace itself won't.

Source https://stackoverflow.com/questions/71346980

QUESTION

Rails - uninitialized constant error by Puma when trying to start the server (WIndows 11)

Asked 2022-Feb-28 at 05:40

I am learning the basics of Rails by creating a simple blog app, as per this guide - https://guides.rubyonrails.org/v6.1/getting_started.html

When I try to run the server using ruby bin\rails server, the server successfully starts on localhost:3000, but I get the following error when I open it in browser:-

...

ANSWER

Answered 2022-Feb-28 at 05:40

Solution:-

Apparently, there was a conflict with the version. As Abhinay mentioned in the comment, I switched to Ruby 2.7.5, and the app started working.

Source https://stackoverflow.com/questions/71290710

QUESTION

Rails 7 Autoloading problem with active job

Asked 2022-Feb-25 at 19:53

I have an app directory in my Rails 7 App, app/beer, and in that folder a file named cool.rb with a defined method execute.

So in an ActiveJob DrinkSudsJob perform method I am calling a method execute from cool.rb as:

...

ANSWER

Answered 2022-Feb-25 at 19:53

If zeitwerk:check passes and app/beer is in the autoload paths, then app/beer/cool.rb defines (and has to define) Cool, not Beer::Cool.

Source https://stackoverflow.com/questions/71258811

QUESTION

ElasticSearch deployment issue: NameError: uninitialized constant Elasticsearch

Asked 2022-Feb-23 at 14:15

I am deploying my rails app via AWS. During the deployment I get the following error.

Automatic configuration of the sidekiq middleware is no longer done. Please see: https://github.com/mhenrixon/sidekiq-unique-jobs/blob/master/README.md#add-the-middleware

This version deprecated the following sidekiq_options

sidekiq_options lock_args: :method_name

It is now configured with:

sidekiq_options lock_args_method: :method_name

This is also true for Sidekiq.default_worker_options

We also deprecated the global configuration options:

default_lock_ttl

default_lock_ttl=

default_lock_timeout

default_lock_timeout=

The new methods to use are:

lock_ttl

lock_ttl=

lock_timeout

lock_timeout= Removing intermediate container 058b1862fa23 ---> d58eac1f9787 Step 22/28 : COPY --chown=app:app . . ---> f91e7b24a602 Step 23/28 : RUN bundle exec rake assets:precompile ---> Running in 49531771f9ca rake aborted! NameError: uninitialized constant Elasticsearch /home/app/webapp/config/initializers/elasticsearch.rb:11:in ' /usr/local/rvm/gems/ruby-2.6.8/gems/bootsnap-1.10.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:48:in load' /usr/local/rvm/gems/ruby-2.6.8/gems/bootsnap-1.10.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:48:in load' /usr/local/rvm/gems/ruby-2.6.8/gems/railties-6.0.4.6/lib/rails/engine.rb:666:in block in load_config_initializer' /usr/local/rvm/gems/ruby-2.6.8/gems/activesupport-6.0.4.6/lib/active_support/notifications.rb:182:in instrument' /usr/local/rvm/gems/ruby-2.6.8/gems/railties-6.0.4.6/lib/rails/engine.rb:665:in load_config_initializer' /usr/local/rvm/gems/ruby-2.6.8/gems/railties-6.0.4.6/lib/rails/engine.rb:625:in block (2 levels) in ' /usr/local/rvm/gems/ruby-2.6.8/gems/railties-6.0.4.6/lib/rails/engine.rb:624:in each' /usr/local/rvm/gems/ruby-2.6.8/gems/railties-6.0.4.6/lib/rails/engine.rb:624:in block in ' /usr/local/rvm/gems/ruby-2.6.8/gems/railties-6.0.4.6/lib/rails/initializable.rb:32:in instance_exec' /usr/local/rvm/gems/ruby-2.6.8/gems/railties-6.0.4.6/lib/rails/initializable.rb:32:in run' /usr/local/rvm/gems/ruby-2.6.8/gems/railties-6.0.4.6/lib/rails/initializable.rb:61:in block in run_initializers' /usr/local/rvm/gems/ruby-2.6.8/gems/railties-6.0.4.6/lib/rails/initializable.rb:50:in each' /usr/local/rvm/gems/ruby-2.6.8/gems/railties-6.0.4.6/lib/rails/initializable.rb:50:in tsort_each_child' /usr/local/rvm/gems/ruby-2.6.8/gems/railties-6.0.4.6/lib/rails/initializable.rb:60:in run_initializers' /usr/local/rvm/gems/ruby-2.6.8/gems/railties-6.0.4.6/lib/rails/application.rb:363:in initialize!' /home/app/webapp/config/environment.rb:5:in ' /usr/local/rvm/gems/ruby-2.6.8/gems/bootsnap-1.10.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in require' /usr/local/rvm/gems/ruby-2.6.8/gems/bootsnap-1.10.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in require' /usr/local/rvm/gems/ruby-2.6.8/gems/zeitwerk-2.5.4/lib/zeitwerk/kernel.rb:35:in require' /usr/local/rvm/gems/ruby-2.6.8/gems/railties-6.0.4.6/lib/rails/application.rb:339:in require_environment!' /usr/local/rvm/gems/ruby-2.6.8/gems/railties-6.0.4.6/lib/rails/application.rb:523:in block in run_tasks_blocks' /usr/local/rvm/gems/ruby-2.6.8/gems/sprockets-rails-3.4.2/lib/sprockets/rails/task.rb:61:in `block (2 levels) in define' Tasks: TOP => environment (See full trace by running task with --trace) The command '/bin/sh -c bundle exec rake assets:precompile' returned a non-zero code: 1

[Container] 2022/02/23 11:37:32 Command did not exit successfully docker build --build-arg RAILS_ENV --build-arg DATABASE_URL --build-arg REDIS_URL --build-arg SECRET_KEY_BASE -t $REPOSITORY_URI:latest . exit status 1 [Container] 2022/02/23 11:37:32 Phase complete: BUILD State: FAILED [Container] 2022/02/23 11:37:32 Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: docker build --build-arg RAILS_ENV --build-arg DATABASE_URL --build-arg REDIS_URL --build-arg SECRET_KEY_BASE -t $REPOSITORY_URI:latest .. Reason: exit status 1 [Container] 2022/02/23 11:37:32 Entering phase POST_BUILD [Container] 2022/02/23 11:37:32 Running command echo Build completed on date Build completed on Wed Feb 23 11:37:32 UTC 2022

[Container] 2022/02/23 11:37:32 Running command echo Pushing the Docker images... Pushing the Docker images...

[Container] 2022/02/23 11:37:32 Running command docker push $REPOSITORY_URI:latest The push refers to repository [413249046650.dkr.ecr.eu-west-1.amazonaws.com/legitimate-development] An image does not exist locally with the tag: 413249046650.dkr.ecr.eu-west-1.amazonaws.com/legitimate-development

[Container] 2022/02/23 11:37:32 Command did not exit successfully docker push $REPOSITORY_URI:latest exit status 1 [Container] 2022/02/23 11:37:32 Phase complete: POST_BUILD State: FAILED [Container] 2022/02/23 11:37:32 Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: docker push $REPOSITORY_URI:latest. Reason: exit status 1 [Container] 2022/02/23 11:37:32 Expanding base directory path: . [Container] 2022/02/23 11:37:32 Assembling file list [Container] 2022/02/23 11:37:32 Expanding . [Container] 2022/02/23 11:37:32 Expanding file paths for base directory . [Container] 2022/02/23 11:37:32 Assembling file list [Container] 2022/02/23 11:37:32 Expanding imagedefinitions.json [Container] 2022/02/23 11:37:32 Skipping invalid file path imagedefinitions.json [Container] 2022/02/23 11:37:32 Expanding imagedefinitions2.json [Container] 2022/02/23 11:37:32 Skipping invalid file path imagedefinitions2.json [Container] 2022/02/23 11:37:32 Phase complete: UPLOAD_ARTIFACTS State: FAILED [Container] 2022/02/23 11:37:32 Phase context status code: CLIENT_ERROR Message: no matching artifact paths found

The file referenced in the line below the error is:

...

ANSWER

Answered 2022-Feb-23 at 14:15

That file uses the Elasticsearch constant in Elasticsearch::Client, but Ruby does not know it.

Do you have the elasticsearch gem in the Gemfile in a group that is included in production? If yes, does it have require: false?

Source https://stackoverflow.com/questions/71236500

QUESTION

Rails Zeitwerk snakecase

Asked 2022-Feb-17 at 21:27

When we have a directory under app/ that we want Zeitwerk to work off of, and say that naming happens to be something like

...

ANSWER

Answered 2022-Jan-09 at 23:22

I believe Zeitwerk has inflectors that can be used for this: https://github.com/fxn/zeitwerk#inflection

Source https://stackoverflow.com/questions/70646337

Community Discussions, Code Snippets contain sources that include Stack Exchange Network

Vulnerabilities

No vulnerabilities reported

Install zeitwerk

Loaders are ready to load code right after calling setup on them:. This method is synchronized and idempotent.

Support

Zeitwerk works with CRuby 2.5 and above. On TruffleRuby all is good except for thread-safety. Right now, in TruffleRuby Module#autoload does not block threads accessing a constant that is being autoloaded. CRuby prevents such access to avoid concurrent threads from seeing partial evaluations of the corresponding file. Zeitwerk inherits autoloading thread-safety from this property. This is not an issue if your project gets eager loaded, or if you lazy load in single-threaded environments. (See https://github.com/oracle/truffleruby/issues/2431.). JRuby 9.3.0.0 is almost there. As of this writing, the test suite of Zeitwerk passes on JRuby except for three tests. (See https://github.com/jruby/jruby/issues/6781.).

Find more information at: