>> There are two CPAN Testers fails: >> >> http://www.cpantesters.org/cpan/report/4ddcddb1-6c58-1014-bec3-a1032b7077ee >> >> http://www.cpantesters.org/cpan/report/39970866-dd9c-11e5-a3ee-89603848fe5a > > Do you have any thoughts on why these occurred on these particular OS/Perl > version combinations? > >> Basically the problem is that >> - the pod directory has both perlpodstyle and perlpodstyle.pod in it >> (how come?!) > > Is it possible that the testers have files left over from previous test runs?
Not the foggiest. That was one of the reasons I included cpan-workers on this, because I’m curious how this came about. I’ve emailed the two people who produced these two fails, asking them to look in the relevant directory and check my theory (just because I can reproduce the error, doesn’t mean that I’ve reproduced how they produced the error. Though it seems likely I have). Somehow when installing perl, they ended up with “perlpodstyle” as well as “perlpodstyle.pod” in their pod directory. And given what the test does, it looks like it was only for that one pod file. One on MacOSX and one on Windows, and different versions of perl. Odd. > Also, could I ask what repository/branch you're working from? I forked Marc’s repo for Pod-Simple, since `corelist --upstream Pod::Simple` says it’s upstream cpan. > If I read your analysis correctly, survey() -- or, more precisely > _make_search_callback() -- already handles '.plx'. It's find() that fails to > handle '.pl’. Yup, I miswrote in my summary. > If that's correct, then why not make both functions handle exactly the same > set of file extensions? Whether that should be specified explicitly or by > regex -- I have no preference. But we could then abstract out the formula > for scanning extensions into a function in a single location. I’ve been resisting the urge to refactor, and just make minimal changes, but you’re right, in this case I should do a teeny bit more. Cheers, Neil
