Tue Feb 03 08:01:56 2009: Request 38067 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: Can't use XML::SAX in a PAR::Packer standalone due to
ParserDetails.ini problem
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: [email protected]
Status: stalled
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=38067 >
On Mon Feb 02 21:13:37 2009, SMUELLER wrote:
> It's not going to be "magically" fixed, sorry.
I agrre with your reasoning. Just for the sake of someone
stumbling over this ticket: there's a "officially sanctioned" way
of hardwiring a certain SAX parser. It's described
SAX::ParserFactory, just set
$XML::SAX::ParserPackage = "XML::SAX::Frobozz";
and so that PAR/pp (or rather Module::ScanDeps) can detect
that you're program is going to require XML::SAX::Frobozz, add:
use XML::SAX::Frobozz;
BTW, it's always a _bad_ idea to rely on implicit configuration
of ParserDetails.ini in production code. I've personally been
burned by this several times. Someone installs just another SAX parser
(or changes the order of entries in ParserDetails.ini) and your
flawlessly running programs break in mysterious ways.
That's because all SAX parsers are _not_ interchangeable when it
comes to certain constructs. One notable difference is whether
strings culled from an XML file are always marked (internally to Perl)
as Unicode strings - even if the string in question only contains
characters from the ASCII set.
