Skip Menu |

This queue is for tickets about the PAR-Packer CPAN distribution.

Report information
The Basics
Id: 132055
Status: open
Priority: 0/
Queue: PAR-Packer

People
Owner: Nobody in particular
Requestors: DBOOK [...] cpan.org
Cc:
AdminCc:

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



Subject: PodStrip filter corrupts __FILE__ in modules
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.
On 2020-03-04 18:57:24, DBOOK wrote: Show quoted text
> 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. Show quoted text
> 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
On Thu Mar 05 03:31:08 2020, RSCHUPP wrote: Show quoted text
> 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
On Thu Mar 05 11:22:46 2020, DBOOK wrote: Show quoted text
> 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
On 2020-03-05 08:22:46, DBOOK wrote: Show quoted text
> 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?
RT-Send-CC: ether [...] cpan.org
On 2020-03-06 00:07:28, ETHER wrote: Show quoted text
> 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
On 2020-03-05 11:22:46, DBOOK wrote: Show quoted text
> 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
Subject: mojo.patch
diff --git a/lib/PAR/Filter/PatchContent.pm b/lib/PAR/Filter/PatchContent.pm index d261f03..c23fb66 100644 --- a/lib/PAR/Filter/PatchContent.pm +++ b/lib/PAR/Filter/PatchContent.pm @@ -30,6 +30,16 @@ sub PATCH_CONTENT () { +{ 'File::Spec->catfile(dirname(__FILE__),' => 'File::Spec->catfile($ENV{PAR_TEMP}, qw(inc lib MIME),', ], + 'Mojo/File.pm' => [ + 'sub curfile { __PACKAGE__->new(Cwd::realpath((caller)[1])) }' => + 'sub curfile { my $fn = (caller)[1]; + $fn = catfile($ENV{PAR_TEMP}, qw(inc lib), $fn) unless file_name_is_absolute($fn); + return __PACKAGE__->new(Cwd::realpath($fn)) }', + ], + 'Mojo/Util.pm' => [ + 'File::Spec->catfile(dirname(__FILE__),' => + 'File::Spec->catfile($ENV{PAR_TEMP}, qw(inc lib Mojo),', + ], 'Mozilla/CA.pm' => [ 'File::Spec->catfile(dirname(__FILE__), "CA", "cacert.pem")' => 'File::Spec->catfile($ENV{PAR_TEMP}, qw(inc lib Mozilla CA cacert.pem))',