Skip Menu |
 

This queue is for tickets about the Moo CPAN distribution.

Report information
The Basics
Id: 116209
Status: open
Priority: 0/
Queue: Moo

People
Owner: Nobody in particular
Requestors: ribasushi [...] leporine.io
Cc:
AdminCc:

Bug Information
Severity: Unimportant
Broken in: (no value)
Fixed in: (no value)



Subject: Misfiring check in _maybe_load_module
A bit contrived, but some of my tests have code (for a good reason), that triggers this behavior: rabbit@Ahasver:~$ perlbrew use 5.8.5 rabbit@Ahasver:~$ perl -e ' if( "$]" < 5.010 ) { require Devel::OverrideGlobalRequire; Devel::OverrideGlobalRequire::override_global_require(sub { # simple escape "please try again, I am going to adjust things" eval { return $_[0]->(); } or do { delete $INC{$_[1]}; die $@; }; }); } require Moo::_Utils; Moo::_Utils::_maybe_load_module( "Can::Not::Haz" ) for (1,2) ' Can::Not::Haz exists but failed to load with error: Can't locate Can/Not/Haz.pm in @INC (@INC contains: /home/rabbit/perl5/perlbrew/perls/5.8.5/lib/5.8.5/x86_64-linux-thread-multi /home/rabbit/perl5/perlbrew/perls/5.8.5/lib/5.8.5 /home/rabbit/perl5/perlbrew/perls/5.8.5/lib/site_perl/5.8.5/x86_64-linux-thread-multi /home/rabbit/perl5/perlbrew/perls/5.8.5/lib/site_perl/5.8.5 /home/rabbit/perl5/perlbrew/perls/5.8.5/lib/site_perl .) at (eval 124) line 5.
Download (untitled) / with headers
text/plain 1.4k
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" ); '
Download (untitled) / with headers
text/plain 704b
On Mon Jul 18 12:25:32 2016, haarg wrote: Show quoted text
> This is not a problem directly in Moo, but a conflict between > Devel::OverrideGlobalRequire and Module::Runtime. >
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 07:09:39 2016, RIBASUSHI wrote: Show quoted text
> On Mon Jul 18 12:25:32 2016, haarg wrote:
> > This is not a problem directly in Moo, but a conflict between > > Devel::OverrideGlobalRequire and Module::Runtime. > >
> > 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.
Do you mean after 2.002002, or including it? And is that only considering stable releases? I don't see any changes that could lead to this, but it would pretty much have to be a load order issue. If you have a link to a failure, it would be appreciated.
Download (untitled) / with headers
text/plain 957b
On Mon Jul 18 14:26:25 2016, haarg wrote: Show quoted text
> > Do you mean after 2.002002, or including it?
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"; '
Download (untitled) / with headers
text/plain 147b
I've filed RT#116305 on Module::Runtime about its incomplete CORE::GLOBAL::require bypass. If that gets resolved, Moo can bump the prereq version.
Download (untitled) / with headers
text/plain 444b
On Tue Jul 19 00:56:45 2016, haarg wrote: Show quoted text
> I've filed RT#116305 on Module::Runtime about its incomplete > CORE::GLOBAL::require bypass. If that gets resolved, Moo can bump the > prereq version.
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.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.