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

[Dan Book via RT]

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: ***@cpan.org
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.

[Roderich Schupp via RT]

Thu Mar 05 03:31:08 2020: Request 132055 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: PodStrip filter corrupts __FILE__ in modules
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@cpan.org
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=132055 >

Post by Dan Book via RT
The filename override causes __FILE__ to then be unusable within the
module since TestModule.pm is not found within cwd.

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.

Post by Dan Book via RT
I wonder why this filter overrides the filename at all. It should be
able to set line numbers and omit the filename.

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

[Dan Book via RT]

Thu Mar 05 11:22:46 2020: Request 132055 was acted upon.
Transaction: Correspondence added by DBOOK
Queue: PAR-Packer
Subject: PodStrip filter corrupts __FILE__ in modules
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=132055 >

Post by Roderich Schupp via RT

Post by Dan Book via RT
The filename override causes __FILE__ to then be unusable within the
module since TestModule.pm is not found within cwd.

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.

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

[Dan Book via RT]

Thu Mar 05 11:23:59 2020: Request 132055 was acted upon.
Transaction: Correspondence added by DBOOK
Queue: PAR-Packer
Subject: PodStrip filter corrupts __FILE__ in modules
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=132055 >

Post by Dan Book via RT

Post by Roderich Schupp via RT

Post by Dan Book via RT
The filename override causes __FILE__ to then be unusable within
the
module since TestModule.pm is not found within cwd.

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.

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

And I will additionally note, this works perfectly fine as long as PodStrip is not run.

-Dan

[Karen Etheridge via RT]

Fri Mar 06 00:07:28 2020: Request 132055 was acted upon.
Transaction: Correspondence added by ETHER
Queue: PAR-Packer
Subject: PodStrip filter corrupts __FILE__ in modules
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=132055 >

Post by Dan Book via RT
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.

Would File::ShareDir work any better here, I wonder?

[Roderich Schupp via RT]

Fri Mar 06 06:27:12 2020: Request 132055 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: PodStrip filter corrupts __FILE__ in modules
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=132055 >

Post by Karen Etheridge via RT

Post by Dan Book via RT
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.

Would File::ShareDir work any better here, I wonder?

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

[Roderich Schupp via RT]

Fri Mar 06 06:33:30 2020: Request 132055 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: PodStrip filter corrupts __FILE__ in modules
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=132055 >

Post by Dan Book via RT
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.

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