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'

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: config/routes.rb a92be1d2a # frozen_string_literal: true MyPluginModule::Engine.routes.draw do get "/examples" => "examples#index" # define routes here end Discourse::Application.routes.draw { mount ::MyPluginModule::Engine, at: "my-plugin" }

Have you seen this topic? If you follow the structure there (and in the plugin-skeleton), things should work pretty smoothly: [image] Structuring a plugin for Rails autoloading Developer Guides 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 autoloading sy… 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?

[image] David Taylor: 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.

That did it! [image] David Taylor: 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. . . )

[image] Robert: that’s exactly a change I made recently. That does make me feel a bit better. . . But did it take you 4 hours? :crying_cat_face: Thanks again, David. I really appreciate your support.

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 :deciduous_tree:

[image] Jay Pfaffman: But did it take you 4 hours? :crying_cat_face: [image] Robert: 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 :sweat_smile:. All this Zeitwerk stuff definitely falls into that category! [image] Robert: some issues take a walk in the local park on the following day to fix :deciduous_tree: :100: :chefs_kiss:

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).

Trouble with Zeitwerk reloading

Development

merefield (Robert) November 29, 2023, 10:30pm 6

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

Topic		Replies	Views
Zeitwerk load error with Rails plugin generator Bug	1	1930	October 19, 2019
Upgrading Discourse to Zeitwerk Development dev-news	13	3548	October 2, 2019
Sidekiq fails to start after Zeitwerk on docker dev Development	24	3841	January 12, 2020
Plugin controller spec: Plugin routes are not drawn Development	7	1278	February 11, 2019
Plugin development: A copy of ApplicationController has been removed from the module tree but is still active! Development	6	1997	January 17, 2020

Trouble with Zeitwerk reloading

Related topics