Skip Menu |
 

This queue is for tickets about the Module-Runtime CPAN distribution.

Report information
The Basics
Id: 95650
Status: open
Priority: 0/
Queue: Module-Runtime

People
Owner: Nobody in particular
Requestors: JDB [...] cpan.org
Cc: dolmen [...] cpan.org
ether [...] cpan.org
ribasushi [...] leporine.io
AdminCc:

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



Subject: require_module() ignores CORE::GLOBAL::require()
Download (untitled) / with headers
text/plain 360b
We use CORE::GLOBAL::require in several applications to load modules not from the local filesystem, but from a different location (memory, a zip file). Modules using Class::Load() now fail to load additional code from the alternate locations. For example https://community.activestate.com/node/10802 turned out to be caused by this change in Module::Runtime.
Download (untitled) / with headers
text/plain 1.9k
Relevant: commit e0affd782303c36cd73841538e531ceaf4a17b59 Author: Zefram <zefram@fysh.org> Date: Thu Feb 6 20:46:57 2014 +0000 suppress any CORE::GLOBAL::require override If require() is overridden, in a way that wraps the core's require(), it is likely that error messages from the core require(), such as those describing a module not being found, will incorporate the filename and line number of the location where the override calls the core require(), rather than the location of the normal require() call that got overridden. As use_package_optimistically() looks at that part of the error message to make its recognition more specific, an override is likely to break its heuristic, making it perceive a real error rather than a missing module. To avoid this, use "CORE::require" instead of just "require", suppressing any override. This means that the module-not-found error message will refer to Module/Runtime.pm even if there is an override. There is some downside from suppressing overrides: they might be doing something useful. The specific case of the overrides from Lexical::SealRequireHints is not a problem, because Module::Runtime incorporates the fix that L:SRH would provide via an override. On the perl versions where M:R's workaround can't operate, L:SRH's pure Perl version can't operate either. L:SRH's XS implementation, which does work on those perl versions, applies to "CORE::require" just as to "require", and doesn't affect error locations. On perl versions prior to 5.8.9, "CORE::require" doesn't actually suppress overrides. On those versions, the incompatibility of use_package_optimistically() with CORE::GLOBAL::require remains. As it seems unfixable, it is left for the time being as a known problem.


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.