On 03/05/2016 03:56 PM, Neil Bowers wrote:
Hi Marc, & CPAN Workers,
I’ve been looking into the final two CPAN Testers fails, and have finally got
to the bottom of them.
The failing test is search50.t, and the problem is where it does the following:
- call survey() to get hash of name => path
- foreach name, then call find() and check it returns the same path
There are two CPAN Testers fails:
http://www.cpantesters.org/cpan/report/4ddcddb1-6c58-1014-bec3-a1032b7077ee
<http://www.cpantesters.org/cpan/report/4ddcddb1-6c58-1014-bec3-a1032b7077ee>
http://www.cpantesters.org/cpan/report/39970866-dd9c-11e5-a3ee-89603848fe5a
<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?
Also, could I ask what repository/branch you're working from?
Basically the problem is that
- the pod directory has both perlpodstyle and perlpodstyle.pod in it
(how come?!)
- the survey() method doesn’t even find perlpodstyle, it just finds
perlpodstyle.pod
- the find() method finds both and it finds perlpodstyle first
- so the test failed
With this understanding I reproduced the failing test.
The problem comes down to two lines of code. In _make_search_callback(), which
is invoked by survey(), we have:
unless( m/^[-_a-zA-Z0-9]+\.(?:pod|pm|plx?)\z/is ) {
So it’s only considering files that end in .pod, .pm, .pl, or .plx
But in find() we have:
foreach my $ext ('', '.pod', '.pm', '.pl') { # possible extensions
As you can see, it first checks for no extension. Also note that it’s not
checking for the ‘.plx’ extension, which survey handles. I’ve never come across
anyone using the .plx extensions, but I guess for a while maybe people did:
http://www.perlmonks.org/?node_id=336713
<http://www.perlmonks.org/?node_id=336713>
I think that the best fix is to make the survey() pattern match files with no
extensions, and also files with the .plx extension.
If I read your analysis correctly, survey() -- or, more precisely
_make_search_callback() -- already handles '.plx'. It's find() that
fails to handle '.pl'.
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.
Note: untested.
Thank you very much.
Jim Keenan
