Bug #38067 for PAR-Packer: Can't use XML::SAX in a PAR::Packer standalone due to ParserDetails.ini problem

Thu Jul 31 08:42:57 2008 ndo [...] unikservice.com - Ticket created

CC:	Gonéri Le Bouder <goneri [...] rulezlan.org>
Subject:	Can't use XML::SAX in a PAR::Packer standalone due to ParserDetails.ini problem
Date:	Thu, 31 Jul 2008 14:42:26 +0200
To:	bug-XML-SAX [...] rt.cpan.org, bug-PAR-Packer [...] rt.cpan.org
From:	Nicolas Dorfsman <ndo [...] unikservice.com>

Hi, I've a problem somewhat similar to : http://rt.cpan.org/Public/Bug/Display.html?id=243 XML::SAX->load_parsers is looking for its file "ParserDetails.ini" in the directory where XML::SAX is 'installed': ==== # get directory from wherever XML::SAX is installed if (!$dir) { $dir = $INC{'XML/SAX.pm'}; $dir = dirname($dir); } my $fh = gensym(); if (!open($fh, File::Spec->catfile($dir, "SAX", PARSER_DETAILS))) { XML::SAX->do_warn("could not find " . PARSER_DETAILS . " in $dir/SAX\n"); return $class; } ==== But with a pp package, modules are hashed and put in a flat directory where there is no ParserDetails.ini file. This file is in $INC{'XML/ SAX.pm'}/incl/lib/SAX Look : [dorfsman@mybox /var/tmp/par-dorfsman/ cache-48311071b9899ece97d9167f761db026701fd69e]$ head -5 fef4da66.pm #line 1 "XML/SAX.pm" # $Id: SAX.pm,v 1.29 2007/06/27 09:09:12 grant Exp $ package XML::SAX; [dorfsman@t22prod /var/tmp/par-dorfsman/ cache-48311071b9899ece97d9167f761db026701fd69e]$ find . -name ParserDetails.ini ./inc/lib/XML/SAX/ParserDetails.ini I'm really embarrassed with this ! Why don't you try to include these ini-parameters in a pm ? Nicolas

Fri Sep 05 10:31:05 2008 smueller [...] cpan.org - Reference to ticket #38068 added

Fri Sep 05 10:31:14 2008 smueller [...] cpan.org - Reference by ticket #38068 added

Fri Sep 05 10:37:57 2008 smueller [...] cpan.org - Correspondence added

I don't have a general fix for this, but I'd like to note that this is *not* the case for "normal" pp-generated executables. If you include the INI file in the package, it'll be normally extracted and found. Only if you use XML::SAX directly from a .par file or from an executable which was built with the --clean option, it won't extract the INI. Personally, I think it's a pretty bad idea to put any configration files in Perl's module path hierarchy, but I may be biased. One possible (but XML-SAX-side) fix would be to add a few lines to the code that searches for the INI file: If the search fails, check whether PAR is loaded and if so, have it try to search in any loaded .par files for the INI file. Untested: my $fh = gensym(); if (!open($fh, File::Spec->catfile($dir, "SAX", PARSER_DETAILS))) { my $path = "lib/XML/SAX/".PARSER_DETAILS(); XML::SAX->do_warn("could not find " . PARSER_DETAILS . " in $dir/SAX\n"); return $class; }

Fri Sep 05 10:38:11 2008 The RT System itself - Status changed from 'new' to 'open'

Fri Sep 05 10:39:56 2008 smueller [...] cpan.org - Correspondence added

I don't have a general fix for this, but I'd like to note that this is *not* the case for "normal" pp-generated executables. If you include the INI file in the package, it'll be normally extracted and found. Only if you use XML::SAX directly from a .par file or from an executable which was built with the --clean option, it won't extract the INI. Personally, I think it's a pretty bad idea to put any configration files in Perl's module path hierarchy, but I may be biased. One possible (but XML-SAX-side) fix would be to add a few lines to the code that searches for the INI file: If the search fails, check whether PAR is loaded and if so, have it try to search in any loaded .par files for the INI file. Untested: ... my $fh = gensym(); if (!open($fh, File::Spec->catfile($dir, "SAX", PARSER_DETAILS))) { my $path = "lib/XML/SAX/".PARSER_DETAILS(); my $ini_text; if ( exists $INC{"PAR.pm"} and defined($ini_text = PAR::read_file($path) ) { # do stuff } else { XML::SAX->do_warn("could not find " . PARSER_DETAILS . " in $dir/SAX\n"); return $class; }

Fri Sep 05 10:41:28 2008 smueller [...] cpan.org - Correspondence added

Sorry, the first of those answers was a premature "<TAB>" while writing the pseudo code.

Tue Jan 27 09:32:14 2009 goneri [...] cpan.org - Correspondence added

Le Ven. Sep. 05 10:41:28 2008, SMUELLER a écrit : Hi, For whose who look for an (ugly) workaround. I add this on the top of my main script: use XML::Simple; { no strict 'refs'; *{"XML::SAX::"}{HASH}{parsers} = sub { return [ { 'Features' => { 'http://xml.org/sax/features/namespaces' => '1' }, 'Name' => 'XML::SAX::PurePerl' } ] }; }

Mon Feb 02 21:13:37 2009 smueller [...] cpan.org - Correspondence added

Marking the issue as stalled because while it's a very valid issue from the user point of view, it results from the combination of an intrinsic property of how PAR::Packer works and bad design of the XML::SAX config loading code. It's not going to be "magically" fixed, sorry. Best regards, Steffen

Mon Feb 02 21:13:41 2009 smueller [...] cpan.org - Status changed from 'open' to 'stalled'

Tue Feb 03 08:01:56 2009 RSCHUPP [...] cpan.org - Correspondence added

On Mon Feb 02 21:13:37 2009, SMUELLER wrote: Show quoted text

> 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.

Tue Feb 03 08:01:57 2009 The RT System itself - Status changed from 'stalled' to 'open'