Trouble with Zeitwerk reloading

[pfaffman (Jay Pfaffman)]

An apparently new test has identified a problem that I think I might have known I had, but had always ignored. Now I can’t ignore it because it now makes the tests fail. Here are my routes:

# frozen_string_literal: true
require_dependency "pfaffmanager_constraint"

Pfaffmanager::Engine.routes.draw do
  get "/" => "pfaffmanager#index", :constraints => PfaffmanagerConstraint.new
  get "/servers" => "servers#index", :constraints => PfaffmanagerConstraint.new
  #      get "#{root_path}/:username/messages/group/:group_name" => "user_actions#private_messages", constraints: { username: RouteFormat.username, group_name: RouteFormat.username }
  get "/servers/group/:group_name" => "servers#index",
      :constraints => PfaffmanagerConstraint.new
  get "/find/:s" => "servers#index", :constraints => PfaffmanagerConstraint.new
  get "/group/:group_name" => "servers#index",
      :constraints => PfaffmanagerConstraint.new
  get "/inventory/:group_name.json" => "servers#inventory",
      :constraints => PfaffmanagerConstraint.new
  get "/servers/:id" => "servers#show",
      :constraints => PfaffmanagerConstraint.new
  get "/servers/:id/edit" => "servers#edit",
      :constraints => PfaffmanagerConstraint.new
  put "/servers/:id" => "servers#update",
      :constraints => PfaffmanagerConstraint.new
  delete "/servers/:id" => "servers#delete",
         :constraints => PfaffmanagerConstraint.new
  put "/status/:id" => "servers#update_status",
      :constraints => AdminConstraint.new
  post "/api_key/:id" => "servers#set_api_key",
       :constraints => PfaffmanagerConstraint.new
  put "/update_server_status/:id" => "servers#update_server_status",
      :constraints => PfaffmanagerConstraint.new
  post "/upgrade/:id" => "servers#queue_upgrade",
       :constraints => PfaffmanagerConstraint.new
  put "/install/:id" => "servers#install",
      :constraints => PfaffmanagerConstraint.new
  get "/ssh_key/:id" => "serverkeys#get_pub_key"
  get "/ssh-key/:hostname" => "serverkeys#get_pub_key_by_hostname",
      :constraints => {
        hostname: %r{[^/]+}
      }
  post "/servers" => "servers#create",
       :constraints => PfaffmanagerConstraint.new
end

Discourse::Application.routes.append do
  mount ::Pfaffmanager::Engine, at: "/pfaffmanager"
end

And it fails like this:

/home/pfaffman/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/actionpack-7.0.7/lib/action_dispatch/routing/route_set.rb:588:in `add_route': Invalid route name, already in use: 'pfaffmana
ger'  (ArgumentError)                                                                                                                                                                         
You may have defined two routes with the same name using the `:as` option, or you may be overriding a route already defined by a resource with the same naming. For the latter, you can restri
ct the routes created with `resources` as explained here:                                                                                                                                     
https://guides.rubyonrails.org/routing.html#restricting-the-routes-created                                                                                                                    
                                                                                                                                                                                              
          raise ArgumentError, "Invalid route name, already in use: '#{name}' \n" \                                                                                                           
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^                                                                                                             
        from /home/pfaffman/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/actionpack-7.0.7/lib/action_dispatch/routing/mapper.rb:1985:in `add_route'   
        from /home/pfaffman/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/actionpack-7.0.7/lib/action_dispatch/routing/mapper.rb:1956:in `decomposed_match'  

[david (David Taylor)]

Have you seen this topic? If you follow the structure there (and in the plugin-skeleton), things should work pretty smoothly:

Structuring a plugin for Rails autoloading

Many plugins include lots of class definitions inside plugin.rb, or use require_relative to load ruby files. That works, but it comes with some disadvantages: No auto-reloading of changes in development. Any changes require a full server restart Getting the require calls in the right order can be painful If they are require’d outside the after_initialize block, then other autoloaded classes/modules may not be available There is a solution! Plugins can lean on the standard Rails autol…

An important part of Zeitwerk autoloading is the file names/paths, so it’s hard to identify the problem from the snippet you shared. Is that in a plugin.rb file? Or some other file?

[pfaffman (Jay Pfaffman)]

@david

Is that in a plugin.rb file? Or some other file?

Sorry. That’s config/routes.rb

But I also have . . . stuff . . . in lib/discourse-pfaffmanager/engine.rb, so maybe I need to move the stuff from routes.rb into lib/pfaffmanager/engine.rb. RTFM some more.

[david (David Taylor)]

I think you probably need to make this change:

- Discourse::Application.routes.append do
+ Discourse::Application.routes.draw do

That way, the file can be ‘reloaded’ multiple times without causing a clash. (‘draw’ will replace any existing route, while ‘append’ will raise an error if there is a clash)

That would also make it match the current plugin-skeleton:

discourse/discourse-plugin-skeleton/blob/a92be1d2aa26c96e45ada26e43033dde38128a4f/config/routes.rb#L8

[pfaffman (Jay Pfaffman)]

That did it!

@david

draw’ will replace any existing route, while ‘append’ will raise an error if there is a clash)

Always so obvious when it’s figured out.

Thanks a zillion.

(Now if I could just get vscode to do the linting when files save, but at least it’s now happening locally before it goes to github. . . )

[merefield (Robert)]

Yep, that’s exactly a change I made recently.

[pfaffman (Jay Pfaffman)]

@merefield

that’s exactly a change I made recently.

That does make me feel a bit better. . .

But did it take you 4 hours?

Thanks again, David. I really appreciate your support.

[merefield (Robert)]

Not on this occasion, sometimes you get lucky ;). On this occasion I happened to read Davids guide and took note of that difference to the code that I had originally been following.

But sure, some issues take a walk in the local park on the following day to fix

[david (David Taylor)]

@pfaffman

But did it take you 4 hours?

@merefield

happened to read Davids guide

FWIW, if I post a guide about something it’s generally because I lost many hours/days trying to figure it out myself . All this Zeitwerk stuff definitely falls into that category!

@merefield

some issues take a walk in the local park on the following day to fix

[pfaffman (Jay Pfaffman)]

So noted. I do eat all of them when you post. I should have searched just for zeitwork and maybe I’d have found it. But even then, the issue was literally just one word that seemed so innocuous.

Now I’m trying to make all of my {{blah... stuff into <blah... . It’s killing me. But I think I understand it (well enough to do it in maybe a few more days).