Re: No . in @INC breaks CPAN

On 11/14/2016 09:11 AM, Todd Rinaldo wrote:
 > Howdy,
 >
 > I've done a write up of a recent change to blead perl. In the future 
it will no longer be possible to count on . being in @INC. This will 
break many of the existing CPAN installs.
 >
 > It was suggested I send the RFC here:
 >
 > 
http://blogs.perl.org/users/todd_rinaldo/2016/11/how-removing-from-inc-is-about-to-break-cpan.html
 >
 > In Perl 5.26, it will no longer be a safe assumption to assume . is 
in @INC. This is a good move towards a more secure Perl, but will break 
the installation of many CPAN modules. For those of you wondering why 
this was done, see this post for more information.
 >
 > Many CPAN modules try to do things like: use inc::Module::Install; 
This depends on . being in @INC. If you invoke Makefile.PL without it, 
the script will not even run.
 >

Here is a use case which I found very soon after building a perl at 
blead with the new option and then installing App::cpanminus against 
that perl.

#####
Summary of my perl5 (revision 5 version 25 subversion 7) configuration:
   Commit id: dd4f16e4ff71ea6d0422d277f00fe430e1d93938
[snip]
     config_args='-des -Dusedevel -Uversiononly 
-Dprefix=/home/jkeenan/testing/nodot -Dman1dir=none -Dman3dir=none 
-Ddefault_inc_excludes_dot'
[snip]
   @INC:
     lib
     /home/jkeenan/testing/nodot/lib/perl5/site_perl/5.25.7/x86_64-linux
     /home/jkeenan/testing/nodot/lib/perl5/site_perl/5.25.7
     /home/jkeenan/testing/nodot/lib/perl5/5.25.7/x86_64-linux
     /home/jkeenan/testing/nodot/lib/perl5/5.25.7
#####

I used ./bin/cpanm to install one of my CPAN distros that has a 
second-level dependency on another one of those distros, 
Perl-StringIdentifier.

#####
Building and testing String-PerlIdentifier-0.05 ... FAIL
! Installing String::PerlIdentifier failed. See 
/home/jkeenan/.cpanm/work/1479138905.14485/build.log for details. Retry 
with --force to force install it.
#####

Let's inspect that build log.

#####
PERL_DL_NONLAZY=1 "/home/jkeenan/testing/nodot/bin/perl" 
"-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef 
*Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
Can't locate t/eligible_chars in @INC (@INC contains: t/ 
/home/jkeenan/.cpanm/work/1479138905.14485/String-PerlIdentifier-0.05/blib/lib 
/home/jkeenan/.cpanm/work/1479138905.14485/String-PerlIdentifier-0.05/blib/arch 
/home/jkeenan/testing/nodot/lib/perl5/site_perl/5.25.7/x86_64-linux 
/home/jkeenan/testing/nodot/lib/perl5/site_perl/5.25.7 
/home/jkeenan/testing/nodot/lib/perl5/5.25.7/x86_64-linux 
/home/jkeenan/testing/nodot/lib/perl5/5.25.7) at t/Auxiliary.pm line 14.
Compilation failed in require at t/01_basic.t line 8.
BEGIN failed--compilation aborted at t/01_basic.t line 8.
# Looks like your test exited with 2 just after 1.
t/01_basic.t ......
Dubious, test returned 2 (wstat 512, 0x200)
Failed 40/41 subtests
#####

Here's what that distro has in/under its 't/' directory.

#####
$ ls t |cat
01_basic.t
02_specified.t
03_min.t
04_max.t
05_default.t
06_no_scores.t
Auxiliary.pm
eligible_chars
#####

#####
$ head t/01_basic.t
# t/01_basic.t - four basic tests
use Test::More tests => 41;
use strict;
use warnings;

BEGIN { use_ok( 'String::PerlIdentifier' ); }
use lib ("t/");
use Auxiliary qw{ _first_and_subsequent };

four_basic_tests() for (1..10);
#####
$ head -15 t/Auxiliary.pm
package Auxiliary;
use strict;
use warnings;
our ($VERSION, @ISA, @EXPORT_OK);
$VERSION = '0.05';
require Exporter;
@ISA         = qw(Exporter);
@EXPORT_OK   = qw(
     _first_and_subsequent
);
*ok = *Test::More::ok;
use lib ('.');

our (%eligibles, %chars);
require "t/eligible_chars";
#####

The test file attempts to load Auxiliary.pm, which is located in the 
same directory as the test file.  Auxiliary.pm in turn 'require's a 
plain-text file, 'eligible_chars', which is also located in t/.  That 
'require' fails.

In this case, adding '.' to the distribution's Makefile.PL made no 
difference.  I had to add "use lib ('.');" to Auxiliary.pm to enable it 
to locate 'eligible_chars', after which 'make test' PASSed.

Based on this example and several other failures, my hunch is that many 
of the failures which we'll see on CPAN are failures of *tests* rather 
than failures of the modules themselves.

Thank you very much.
Jim Keenan