I made a rapid release of Workflow (Workflow 0.32_4) - which should address some of our problems, but the number of failing tests are still very high and I see more and more of the same diagnostics.
So I started to dig into the problems.
Since none of these are emitted from the Workflow code base I did some googling in the first one.
One of the links I found googling was at Perlmonks so I clicked that right away
Here is the explanation, snipped from Perlmonks, it does however originate from a test report:
The problem in this case is a bug in the XML::SAX::RTF installer,
which registers itself in ...lib.../XML/SAX/ParserDetails.ini.
This ini file is used to determine the default SAX parser and
since XML::SAX::RTF was installed most recently, it is the default.
Unfortunately, XML::SAX::RTF is not an XML parser (despite
generating SAX events) so it should be removed from the
ParserDetails.ini file.
I have reported this problem to the module maintainer some time
ago, but I will try again and submit a patch this time.
Thanks for the test.
Grant
I wrote Grant to inquire on the status of the problem. Referring to the RT ticket
I installed XML::SAX::RTF and I could reproduce the error.
I wrote Andreas Köenig, whom I had just recently met at YAPC::Europe because he had sent me some test reports indicating failure as well and asked him to send me his: XML/SAX/ParserDetails.ini
His file did however look different from mine, but the reports looked somewhat the same. Since he did not have XML::SAX::RTF installed. So I started to examine XML::SAX and I came to the conclusion that this particular snippet is the problem (from XML::SAX::ParserFactory).
if (@{$self->{KnownParsers}}) {
return $self->{KnownParsers}[-1]{Name};
}
else {
return "XML::SAX::PurePerl"; # backup plan!
}
So as Grant stated earlier, the most recent XML::SAX parser installation is the parser used. It is quite an easy fix, take the XML::SAX::PurePerl (the topmost in the XML/SAX/ParserDetails.ini) so we do not get behavior based on installation behavior.
The problem is then how do we fix this?
I discussed with another Workflow developer on our mailing list about indicating requirements for modules not used directly by Workflow and that solution is not good and since XML::SAX is well encapsulated inside XML::Simple and the parser is well encapsulated within XML::SAX, we cannot really control this, since it is all a matter of configuration.
So what we might have to do is write a test, which attempts to find out what parser is used and then bail (fail) or continue... this will however still result in failing tests indicating that Workflow fails.
Installation of modules is mostly done by people so the XML::SAX configuration is our weakest link, I would prefer to rewrite the above snippet to be:
if (@{$self->{KnownParsers}}) {
#defaults to XML::SAX::PurePerl
return $self->{KnownParsers}[0]{Name};
}
else {
return "XML::SAX::PurePerl"; # backup plan!
}
So we know we always get XML::SAX::PurePerl unless the user has changed the precedence in his/her XML/SAX/ParserDetails.ini.
This will however break a lot of XML::SAX installations, but the current implementation is stupid and yields unpredictable behavior - and we do not like unpredictable do we?
I have not gotten my head around the XML::SAX feature system, perhaps this could be used to tweak XML::SAX into behaving more predictably, but that will require patches to all parser distributions, XML::Simple and other places beyond my control and I feel like a I am straying from what I intentionally wanted to do, which was releasing Workflow 0.32.
About the other problem, I think this might have to be related to a definition of root directory, but I have not investigated this any further...
This situation calls for a quote from the Coneheads movie trailer (I have never seen the movie)
Coast guard using megaphone addressing refugees on a boat:
We appreciate your situation, but we have problems of our own
I am not sure the quote is correct, but it always pop to mind when situations like this occur.
