FatPacker vs PAR

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Hi all,

Does anyone have experience using the two for creating a single-file distributable executable/script? How would you compare the pro's and con's of each?

As I understand it, FatPacker is the newer (, simpler?), and Pure-Perl solution. It produces Perl script instead of binary. But currently it lacks filters, which in PAR can be used to obfuscate/encrypt source code.

What I want to know is how well each does its job processing real-world/complex Perl modules and applications and what issues they might have.

Also, does anyone use other alternatives?

Comment on FatPacker vs PAR

Replies are listed 'Best First'.
Re: FatPacker vs PAR by Anonymous Monk on May 11, 2011 at 08:54 UTC
Current choices PAR/pp works for everything. CAVA pack works for everything. perl2exe works for everything. perlapp works for everything. Honorable mention Perl::Dist works for win32 CPANPLUS::Dist::RPM CPANPLUS::Dist::Deb PPM::Make PAR::WebStart ... MSI/RPM/DEB/apt-get/7z/rar... Work Inline::Module works for one .pm file. App::FatPack works for a bunch of .pm files. perlcc , experimental shar/park/Compress::SelfExtracting work, probably "Current choices" are the only choices to consider, they all work about the same, and they're all current, and they work. "Honorable mention" also work, but they either do more, or do less, or ... if you have a need for such, you already using them, for example to enhance the "Current choices". "Work" are sometimes basic, sometimes outdated, sometimes experimental ... fancy toys :) More work than solution :) Respectable, workable, but still work :)	[reply]
Re^2: FatPacker vs PAR by Anonymous Monk on May 12, 2011 at 00:46 UTC
Thanks for the nice summary! I toyed around with PAR yesterday. It has a lot of features but I had a few issues with it: First, it extracts everything the first run to /tmp/par-$USER/cache-$GUID/. This makes the startup of the first run noticably slow. It doesn't share the cache with other users or even different version of the same binary. And of course, it seems inelligent? I thought the point of using zip is so that we can have a virtual filesystem and modules can be loaded on demand from it? Second, filters didn't seem to work on modules added via -a/-A. Tried the -F option (as well as the -f, which works) with the Squish and Crypto filters. The modules extracted to the cache were all unfiltered. I might have to fiddle with it some more. I'm going the FatPacker route. It seems far simpler and fits my need for now.	[reply]
Re^3: FatPacker vs PAR by arpad.szasz (Pilgrim) on May 12, 2011 at 20:45 UTC
If You are on a GNU/Linux platform You can try staticperl, that generates a binary executable from Your program. :)))))	[reply]
Re: FatPacker vs PAR by GrandFather (Saint) on May 11, 2011 at 04:08 UTC
For Windows distribution I use Cava Packager. True laziness is hard work	[reply]
Re: FatPacker vs PAR by ww (Archbishop) on May 11, 2011 at 18:08 UTC
Minor but not insignificant nit (for most reasonable values of "encrypt"): can be used to /\^minimally obfuscate ~~/encrypt~~ source code.	[reply]