[rt.cpan.org #38067] Can't use XML::SAX in a PAR::Packer standalone due to ParserDetails.ini problem

2021-01-13 Thread Roderich Schupp via RT 
Wed Jan 13 05:58:02 2021: 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: n...@unikservice.com
  Status: open
 Ticket https://rt.cpan.org/Ticket/Display.html?id=38067 >


Cleaning out old tickets...

[rt.cpan.org #38067] Can't use XML::SAX in a PAR::Packer standalone due to ParserDetails.ini problem

2009-02-03 Thread RSCHUPP via RT 
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: n...@unikservice.com
  Status: stalled
 Ticket 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.

[rt.cpan.org #38067] Can't use XML::SAX in a PAR::Packer standalone due to ParserDetails.ini problem

2009-02-03 Thread Steffen Mueller via RT 
Mon Feb 02 21:13:37 2009: Request 38067 was acted upon.
Transaction: Correspondence added by SMUELLER
   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: n...@unikservice.com
  Status: open
 Ticket https://rt.cpan.org/Ticket/Display.html?id=38067 >


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

[rt.cpan.org #38067] Can't use XML::SAX in a PAR::Packer standalone due to ParserDetails.ini problem

2009-01-27 Thread Gonéri LE BOUDER via RT 
Tue Jan 27 09:32:14 2009: Request 38067 was acted upon.
Transaction: Correspondence added by GONERI
   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: n...@unikservice.com
  Status: open
 Ticket https://rt.cpan.org/Ticket/Display.html?id=38067 >


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'
}
]
};
}

[rt.cpan.org #38067] Can't use XML::SAX in a PAR::Packer standalone due to ParserDetails.ini problem

2008-09-05 Thread Steffen Mueller via RT 
Fri Sep 05 10:39:56 2008: Request 38067 was acted upon.
Transaction: Correspondence added by SMUELLER
   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: open
 Ticket http://rt.cpan.org/Ticket/Display.html?id=38067 >


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;
}

[rt.cpan.org #38067] Can't use XML::SAX in a PAR::Packer standalone due to ParserDetails.ini problem

2008-09-05 Thread Steffen Mueller via RT 
Fri Sep 05 10:41:28 2008: Request 38067 was acted upon.
Transaction: Correspondence added by SMUELLER
   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: open
 Ticket http://rt.cpan.org/Ticket/Display.html?id=38067 >


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

[rt.cpan.org #38067] Can't use XML::SAX in a PAR::Packer standalone due to ParserDetails.ini problem

2008-09-05 Thread Steffen Mueller via RT 
Fri Sep 05 10:37:57 2008: Request 38067 was acted upon.
Transaction: Correspondence added by SMUELLER
   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: new
 Ticket http://rt.cpan.org/Ticket/Display.html?id=38067 >


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;
}