[rt.cpan.org #132055] PodStrip filter corrupts __FILE__ in modules

Wed Mar 04 18:57:24 2020: Request 132055 was acted upon.
Transaction: Ticket created by DBOOK
Queue: PAR-Packer
Subject: PodStrip filter corrupts __FILE__ in modules
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: [email protected]
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=132055 >


test.pl:

use TestModule;

TestModule.pm:

print __FILE__, "\n";

pp -o test test.pl; ./test

TestModule.pm

env PAR_VERBATIM=1 pp -o test test.pl; ./test

/tmp/par-6772696e6e7a/cache-3389c9f99dff4f9a1680ee679c53debbe9e2e918/inc/lib/TestModule.pm

The filename override causes __FILE__ to then be unusable within the module since TestModule.pm is not found within cwd.

I wonder why this filter overrides the filename at all. It should be able to set line numbers and omit the filename.

Thu Mar 05 03:31:08 2020: Request 132055 was acted upon.
Transaction: Correspondence added by RSCHUPP
Don't do that then.

And yes, there are modules that behave differently when run from a packed executable.
PAR/Filter/PatchContent.pm contains workarounds for the known ones.
My guess is that the filename is for the benefit of the "embedded files"
(cf. https://metacpan.org/pod/distribution/PAR/lib/PAR/Tutorial.pod#Anatomy-of-a-Self-Contained-PAR-executable)
as these are extracted with mangled names like "776cb274.pm". Hence any runtime
diagnostic messages originating from one of these modules would be pretty useless.

Cheers, Roderich

Thu Mar 05 11:22:46 2020: Request 132055 was acted upon.
Transaction: Correspondence added by DBOOK
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=132055 >
FWIW, the distribution that ran into this problem is Mojolicious. It uses the path to modules to find its bundled resource files in several places.

-Dan

Thu Mar 05 11:23:59 2020: Request 132055 was acted upon.
And I will additionally note, this works perfectly fine as long as PodStrip is not run.

-Dan

Fri Mar 06 00:07:28 2020: Request 132055 was acted upon.
Transaction: Correspondence added by ETHER
Would File::ShareDir work any better here, I wonder?

Fri Mar 06 06:27:12 2020: Request 132055 was acted upon.
Transaction: Correspondence added by RSCHUPP
That was my thought, too.

Note that using __FILE__ at runtime isn't the only problem here.
The bundled resource files need special treatment when packing a script:
Module::ScanDeps doesn't detect them automagically so they won't get packed.

Cheers, Roderich

Fri Mar 06 06:33:30 2020: Request 132055 was acted upon.
On 2020-03-05 11:22:46, DBOOK wrote:
The explicit use of __FILE__ in Mojo::Util is easily fixed.
The implicit use via "(caller)[1]" in Mojo::File is a bit trickier.

Does the attched patch help?

Cheers, Roderich