I doubt that - do you really think that this is the reason "commercial products" don't have a Perl API? Perl is dead.
Perl is dead and we're a group of zombies... I fully agree that the reason "missing APIs of commercial products" isn't the best, but Perl is not dead ;-) 2013/4/5 Roderich Schupp <roderich.sch...@googlemail.com> > 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) >
