[=inc::Plugin] is not supported in Dist::Zilla::Tester

[karenetheridge]

This test blows up with "Required plugin [=inc::MyMetadata] isn't installed...."

use strict;
use warnings FATAL => 'all';

use Test::More;
use Dist::Zilla::Tester;
use Test::DZil;

my $tzil = Builder->from_config(
  { dist_root => 't/empty_dir' },
  {
    add_files => {
      'source/dist.ini' => simple_ini(
        [ GatherDir => ],
        [ MetaJSON => ],
        [ '=inc::MyMetadata' ],
      ),
      'source/inc/MyMetadata.pm' => <<PLUGIN
package inc::MyMetadata;
use Moose;
with 'Dist::Zilla::Role::MetaProvider';
sub metadata { {} }
1;
PLUGIN
    },
  },
);

$tzil->build;

Creating a similar corpus directory in the filesystem and running 'dzil build' on it works -- does the test builder not know how to support =inc plugins? I'm tracing through the code and nothing jumps out as suspicious.

[karenetheridge]

Adding this before the ->build call works: unshift @INC, 't/empty_dir'; --- so it looks like the test builder should do this first.

Alternatively, we need to chdir into the corpus directory so the normal '.' entry in \@INC picks up the inc/ dir, as would happen with a normal 'dzil build' where we are already in the corpus directory. Perhaps the test builder should always do this???

[rjbs]

I may have fixed this in f903aa6 on dev-v6.

Do you have a test? Fancy crafting one?

[kentfredric]

the normal '.' entry in \@INC picks up the inc/ dir,

This is looking like it could go away by default sometime after 5.25

https://rt.perl.org/Public/Bug/Display.html?id=127810

May break lots of CPAN.

( Yes, the ABSTRACT of that issue suggests "give us an option to make this happen", but by the time you reach the bottom its "this should be complied in by default with a way to get rid of it via %ENV" )

[plicease]

'.' can be removed from @INC by default as of 5.25.7:

https://metacpan.org/pod/release/EXODIST/perl-5.25.7/pod/perldelta.pod#and-INC

Under this configuration, t/tester-local-plugins.t fails.

[karenetheridge]

The problem is not really in this distribution at all, but way back in Config::MVP -- where the special handling of local plugins is done.

[plicease]

Interesting, Config::MVP installs fine for me, so it seems that it isn't testing for this.