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
> 

Reply via email to