That doesn't help those of us with a habit of naming our test modules t::Foo::Bar
I think there's a fair few things with copies of test modules bundled that way. Adam > On 14 Nov. 2016, at 11:45 am, Karen Etheridge <p...@froods.org> wrote: > > > 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. > > I would agree. I'd also encourage authors to not add "use lib '.';" to their > tests to fix these issues, but rather move the test modules to t/lib and > instead "use lib 't/lib'". > > >> On Mon, Nov 14, 2016 at 10:56 AM, James E Keenan <jk...@verizon.net> wrote: >> >> 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 >