Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Rails 6 Zeitwerk Mode for Dependencies Autoloading breaks external Agents #2845

Open
alessio-signorini opened this issue Jul 20, 2020 · 8 comments

Comments

@alessio-signorini
Copy link
Contributor

alessio-signorini commented Jul 20, 2020

External agents which rely on huginn_agent are loaded during initialization and injected in Agent::TYPES.

Rails 6 implements a new dependencies autoloading system called Zeitwerk Mode.

Unfortunately this change breaks huginn_agent paradigm because Agent::TYPES will be rebuild from scratch after initialization and only contain default agents.

It also generates a lengthy warning when running tests

DEPRECATION WARNING: Initialization autoloaded the constants AssignableTypes,
MarkdownClassAttributes, JsonSerializedField, RdbmsFunctions, WorkingHelpers,
LiquidInterpolatable, HasGuid, LiquidDroppable, DryRunnable, SortableEvents,
OwnedByValidator, Agent, and FormConfigurable.

Being able to do this is deprecated. Autoloading during initialization is going
to be an error condition in future versions of Rails.

Reloading does not reboot the application, and therefore code executed during
initialization does not run again. So, if you reload AssignableTypes, for example,
the expected changes won't be reflected in that stale Module object.

These autoloaded constants have been unloaded.

Please, check the "Autoloading and Reloading Constants" guide for solutions.
 (called from <top (required)> at /home/alessio/huginn/config/environment.rb:5)
@alessio-signorini
Copy link
Contributor Author

Current workaround is to opt-out of Zeitwerk Mode adding

config.autoloader = :classic

to config/application.rb but a more permanent fix needs to be implemented.

@dsander
Copy link
Collaborator

dsander commented Jul 21, 2020

Hmm this is odd I am using a bunch of Agent gems in production and don't seem to have any issues with it. In which environments are you seeing the issue?

@alessio-signorini
Copy link
Contributor Author

alessio-signorini commented Jul 21, 2020

I too have a production system that kept/keeps chugging along and drove me nuts when suddenly (upgrade to Rails 6) I could no longer develop locally external gems!

I just looked at your commits and on May 26th you did force config.autoloader to classic.

@dsander
Copy link
Collaborator

dsander commented Jul 21, 2020

Urg, that is annoying I thought I still had Agent gems active in my development environment. I guess the auto-reloader changed in some way that it breaks.I think we should still try to support the new autoloader because I am assuming Rails will get rid of the old one at some point, but I don't know when I have the time to work on it.

@alessio-signorini
Copy link
Contributor Author

@dsander - now that huginn_agent is part of the master codebase, we could improve/expand the definition of TYPES to include Agent gems and easily/cleanly solve this. I can take a stab at it if it sounds good to you.

@dsander
Copy link
Collaborator

dsander commented Jul 21, 2020

Sure, that would be great!

@alessio-signorini
Copy link
Contributor Author

Patch is ready and quite simple (example below). As soon the change in huginn_agent is merged (will make things cleaner) I'll open a PR for this.

    def types
      all_agents.map(&:constantize)
    end

    def all_agents
      const_get(:TYPES) + HuginnAgent.additional_agents
    end

    def valid_type?(type)
      all_agents.include?(type)
    end

@dsander
Copy link
Collaborator

dsander commented Jul 29, 2020

That's great! Can you open a PR to Huginn as well? You can switch the branch of huginn_agent in the Gemfile similar to this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants