On Fri, Apr 5, 2013 at 12:08 AM, Tony Edwardson <tony.edward...@gmail.com> wrote:
> Does anyone have any major objection to me using the PAR namespace in this way No objection from me. > For this to work, I need to be able to create a native perl module (without > dependency on any os specific modules or shared libraries) which is able to > use these par files. > Unfortunately, the PAR module relies on Archive::Zip which in turn needs the > Compress::Raw::Zlib module which are OS specific needing a compiler. > I would like to create a PAR::Lite module which performs a subset of the PAR > functionality using something like Compress::Zlib::Perl to just handle using > PAR files as an additional resource of CPAN modules. That's a bogus argument. AFAIK any recent Perl distribution (on Windows) already includes Archive::Zip and its dependencies. Also lots of useful Perl modules have XS parts, so if you want to use these you need a C compiler anyway to install them. If you want to spare users the DIY part, look at PPM. People on the list might correct me, but I think the major use of the PAR family of modules is not to create jar-like archives, but to create standalone executables. A pure-Perl PAR reimplementation won't help in this use case. I've contemplated the idea to create a stripped down and radically simplified PAR::Packer that would to just that. However, it would be implemented in the opposite direction you're heading - using InfoZip's self extractor (and nothing else) on the extracting side and bog-standard Archive::Zip on the packing side (plus a dependency analyser like Module::ScanDeps). > This could persuade Third Party companies to provide perl api's to > commercial products via obfuscated and bleached (and possibly encrypted) PAR > files I doubt that - do you really think that this is the reason "commercial products" don't have a Perl API? Perl is dead. Cheers, Roderich (RSCHUPP on CPAN)
