[rt.cpan.org #110307] Option -F does not encrypt files in inc\lib

[Joachim Wesenberg via RT]

Sun Dec 13 11:04:15 2015: Request 110307 was acted upon.
Transaction: Ticket created by ***@gmail.com
Queue: PAR-Packer
Subject: Option -F does not encrypt files in inc\lib
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@gmail.com
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=110307 >


Hallo support team,
'.pl'-files ending up in inc\lib are not encrypted using the pp-option
'-F'. However, files ending up in inc\scripts are encrypted as expected.

pp -f Crypto -F Crypto ......

Windows 10
Strawberry Perl - 5.22.0.1 (64-bit)
PAR::Packer - 1.028
pp - 0.992

Thanks very much in advance for your effort fixing the problem.

Best regards

[Roderich Schupp via RT]

Sun Dec 13 11:50:48 2015: Request 110307 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: Option -F does not encrypt files in inc\lib
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@gmail.com
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=110307 >


The long option corresponding to -F is called --modfilter for a reason: *.pl files (other than the script to be packed) are categorized (by Module::ScanDeps) as "data", rather than "module".

Cheers, Roderich

[Joachim Wesenberg via RT]

Sun Dec 13 12:28:33 2015: Request 110307 was acted upon.
Transaction: Correspondence added by ***@gmail.com
Queue: PAR-Packer
Subject: Re: [rt.cpan.org #110307] Option -F does not encrypt files in inc\lib
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@gmail.com
Status: rejected
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=110307 >


Roderich,
thanks for your quick response. Obviously I interpreted the -F option
wrong. Is there any way to encrypt .pl-files which are not considered as
"modules" by ScanDeps? The application has a lot of subroutines which
are included using 'do' as separate .pl-files by the main script.

If there is any smart way or workaround - please let me know.

Thanks again

Joachim Wesenberg
Stabelsteiner Weg 35
D-61267 Neu-Anspach
Germany

E-Mail: ***@gmail.com
Phone: [phone]
Mobile: [phone]

Post by Joachim Wesenberg via RT
<URL: https://rt.cpan.org/Ticket/Display.html?id=110307 >
The long option corresponding to -F is called --modfilter for a reason: *.pl files (other than the script to be packed) are categorized (by Module::ScanDeps) as "data", rather than "module".
Cheers, Roderich

[Roderich Schupp via RT]

Sun Dec 13 13:12:02 2015: Request 110307 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: Option -F does not encrypt files in inc\lib
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@gmail.com
Status: rejected
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=110307 >


On 2015-12-13 12:28:33, ***@gmail.com wrote:
It's more that the docs are
Is there any way to encrypt .pl-files which are not considered

Post by Joachim Wesenberg via RT
as
"modules" by ScanDeps? The application has a lot of subroutines which
are included using 'do' as separate .pl-files by the main script.
If there is any smart way or workaround - please let me know.

The easiest solution is to patch your version of PAR/Packer.pm like this:

--- lib/PAR/Packer.pm.orig 2015-11-19 10:07:42.016710501 +0100
+++ lib/PAR/Packer.pm 2015-12-13 18:50:00.188377284 +0100
@@ -813,7 +813,7 @@

$self->_vprint(2, "... adding $map{$pfile} as ${root}lib/$pfile");

- if ($text{$pfile} or $pfile =~ /utf8_heavy\.pl$/i) {
+ if ($text{$pfile} or $pfile =~ /\.pl$/i) {
my $content_ref = $mod_filter->($map{$pfile}, $pfile);

$full_manifest->{ $root . "lib/$pfile" } =


I could do this in general, but I'm not sure about the consequences: if someone was using "pp -F Crypt .." with non-script .pl files before, this might break if she was accessing the .pl files with something that doesn't ultimately result in a do().

Another solution would be to rename all your .pl file to .al (and change all do() statements accordingly), since Module::ScanDeps classifies these as "autoload" and PAR::Packer treats "autoload" the same as "module". Actually, I like this one better, since that's what your application is doing, it just uses a similar approach as AutoSplit.

Cheers, Roderich