Bug #116209 for Moo: Misfiring check in _maybe_load_module

This is not a problem directly in Moo, but a conflict between Devel::OverrideGlobalRequire and Module::Runtime. Devel::OverrideGlobalRequire uses string evals to maintain the calling package, but does not maintain the calling filename or line number. Module::Runtime is very strict about the error messages it expects. It checks for the filename and line number in a failed require, and uses CORE::require to avoid any attempts to interfere. It also localizes __DIE__. As commented on in D::OGR (https://metacpan.org/source/DAGOLDEN/Devel-OverrideGlobalRequire-0.001/lib/Devel/OverrideGlobalRequire.pm#L43-48) on some perl versions a CORE::require call will be compiled as a CORE::GLOBAL::require call if evaled (or in our case required) while a CGr override is in place. This means Module::Runtime fails to bypass the override and gets an error message it doesn't expect. D::OGR should probably maintain the filename and line number from context. Module::Runtime should probably work around CORE::require sometimes calling CORE::GLOBAL::require. I generally think that Module::Require's attempts to bypass any interference to be misguided. I would prefer that it simplified its checks, and stopped using CORE::require or localizing __DIE__. Simplified test case: perl -e ' require Devel::OverrideGlobalRequire; Devel::OverrideGlobalRequire::override_global_require(sub { $_[0]->(); }); require Module::Runtime; Module::Runtime::use_package_optimistically( "Can::Not::Haz" ); '

On Mon Jul 18 12:25:32 2016, haarg wrote: Show quoted text
Yes, I should have investigated further. Apologies, I was filing this in a hurry :( While I do understand the underlying problem (remember - I was the first to flag it as ARGHHHHH!!!), it is a change in Moo between 2.002002 and current that exposed the underlying issue upwards, at least within my CI. What I failed to realize is that my (and by extension your) reduced case is not sufficient to highlight what happened. I am fine with closing this ticket for the time being as inactionable until I get a new round of tuits to revisit this.

On Mon Jul 18 14:26:25 2016, haarg wrote: Show quoted text
Sorry again - red herring. A very subtle change in the test stack exposed a particular load order that has not been encountered before. Here is the shortest reproduction with latest stable Moo on any perl (the actual Moo version does not seem to matter - the warning is there at least as far back as 2.0, possibly more). Note - D::OGR is on my backlist of things to fixup, so please do not yet spend much time on patching it up - I won't be able to ship anything in this area for weeks if not more. perl -e ' require Devel::OverrideGlobalRequire; Devel::OverrideGlobalRequire::override_global_require(sub { $_[0]->() }); # simulate non-existence, it may in fact *really* not be there require Devel::Hide; Devel::Hide->import("Class::XSAccessor"); require Moo; Moo->import; has( foo => ( is => "rw" ) ); __PACKAGE__->new; warn "end"; '

On Tue Jul 19 00:56:45 2016, haarg wrote: Show quoted text
Do note that what you linked to in D::OGR is actually Zefram's own code: https://metacpan.org/source/ZEFRAM/Lexical-SealRequireHints-0.010/lib/Lexical/SealRequireHints.pm#L179-197 (I was the one who copied it). Circular turtles all the way down.