Bundler, Zeitwerk & Roda Plugins #356
Comments
|
One root of the issue (or perhaps better stated as the reason this issue became apparent) is the non-conformity of the plugin to bundler/rubygems standards for the default entry-point load files: A normal entry point for this gem name, IIRC, would have been |
|
Also, very interesting to note that (timestamps removed):
|
|
Unfortunately, I don't have any insight here. The As you suspected, it isn't a bug in Roda, so I'll close this. However, if you find out more regarding the cause, I'd be interested. |
My deepest fear is that my dependencies are not deterministically loaded into my published Docker images... Really hoping that isn't the case, but I'm working with an extremely legacy build incantation that still uses "eye of newt" as an ingredient. |
|
My deepest fear was true. Sorry for the waste of time! |
I'm trying to understand an issue I'm seeing in a deployed environment, but can't reproduce locally, even when I turn on Rails' eager loading.
I'm reporting it here because it appears to have bearing on how roda plugin authors write their code to be auto-required by bundler, vs autoloaded by zeitwerk, and I'm hoping there is a way to be/do both without conflict.
It's entirely reasonable to say it's not relevant to roda / rodauth, and close this issue, even so it may have value as a closed issue that gets indexed by search engines.
Stack
Context: Background
Superficially, the error I have seems like this one.
It was ultimately fixed by bootsnap 1.9.4 here.
Thus I'm fairly certain the above bug is not my issue.
Context: Immediately preceding `[Bootsnap] miss` messages
Context: Error Backtrace
Command that fails
bundle exec sidekiqSpecific error
A few things I noticed.
a. rails, and
tiny_admin, which also depends onroda, are the most relevantb. only others are
service_actor,ajax-datatables-rails, and thedry-rbfamily of gems[Bootsnap] missjust before the rodauth-related[Bootsnap] missmessages. It's only mildly interesting because TinyAdmin is a roda plugin that is self-loaded by Zeitwerk.config.ru, and the backtrace goes through myRails.application.initialize!line inconfig/environment.rb, which happens afterrequire_relative "application", which is what loads bundler.rodauth-become_accountdoes not load itself via bundler, since it has no file in the expected location for bundler to load, based on the name of the gem. So when rubygems requires the gem, actually nothing is loaded.rodauth_app.rb:rodauth-become_accountyet, but I expect it will fix the issue, now that I've typed this up... except of course the require statement would be:require "rodauth/features/become_account", and if I do that before requiringtiny_admin, maybe I can have it load beforezeitwerk, if that matters.My guess is that roda plugin gems need to be explicitly required, since they likely won't follow the bundler pattern, and they seem to be capable of hitting an edge case in zeitwerk as well.
Again, I am not able to reproduce this outside my deployed docker environments. I can't make it fail locally, even with Rails eager loading turned on.
Posting it here for awareness, in case anyone has any ideas, and perhaps @jeremyevans has some insight into how plugin authors might mitigate this by either following the rubygems/bundler pattern of having a root lib file of the gem's name where expected, or insight into something I've missed.
Will update when I have a fix!
The text was updated successfully, but these errors were encountered: