PAR-Packer
PAR-Packer copied to clipboard
Published
20 hours ago •
rschupp
rschupp
PodStrip filter corrupts __FILE__ in modules [rt.cpan.org #132055]
Migrated from rt.cpan.org#132055 (status was 'open')
Requestors:
Attachments:
From [email protected] on 2020-03-04 23:57:24 :
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.
From [email protected] on 2020-03-05 08:31:08 :
On 2020-03-04 18:57:24, DBOOK wrote:
> 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.
> 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
From [email protected] on 2020-03-05 16:22:46 :
On Thu Mar 05 03:31:08 2020, RSCHUPP wrote:
> On 2020-03-04 18:57:24, DBOOK wrote:
> > 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
From [email protected] on 2020-03-05 16:23:59 :
On Thu Mar 05 11:22:46 2020, DBOOK wrote:
> On Thu Mar 05 03:31:08 2020, RSCHUPP wrote:
> > On 2020-03-04 18:57:24, DBOOK wrote:
> > > 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
From [email protected] on 2020-03-06 05:07:28 :
On 2020-03-05 08:22:46, DBOOK wrote:
> 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?
From [email protected] on 2020-03-06 11:27:12 :
On 2020-03-06 00:07:28, ETHER wrote:
> On 2020-03-05 08:22:46, DBOOK wrote:
>
> > 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
From [email protected] on 2020-03-06 11:33:30 :
On 2020-03-05 11:22:46, DBOOK wrote:
> On Thu Mar 05 03:31:08 2020, RSCHUPP wrote:
> 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
