search

rjbs / Dist-Zilla

scary tools for building CPAN distributions
http://dzil.org/
186 stars 152 forks source link

t/tester-local-plugins.t fails test without '.' in @INC #581

Closed kentfredric closed 3 years ago

kentfredric commented 7 years ago

Unsure if this is related to #580 or not

t/zzz-check-breaks.t ............ ok

#   Failed test 'config does not blow up with "Required plugin inc::MyMetadata isn't installed."'
#   at t/tester-local-plugins.t line 36.
#          got: 'Required plugin inc::MyMetadata isn't installed.
# 
# Run 'dzil authordeps' to see a list of all required plugins.
# You can pipe the list to your CPAN client to install or update them:
# 
#     dzil authordeps --missing | cpanm
# 
# '
#     expected: undef
# Looks like you failed 1 test of 1.
t/tester-local-plugins.t ........ 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests
latk commented 7 years ago

Aka. “Dist::Zilla 6.010 can't load plugins from inc/ under perl 5.26”. As a workaround one can export PERL_USE_UNSAFE_INC=1 in the current shell, but this is really something that dzil should support by itself.

Note that in some cases dzil handles inc:: modules specially, e.g. by prioritizing them in the authordeps --missing command (see the Dist::Zilla::Util::AuthorDeps::extract_author_deps() function). This prioritization seems to make it impossible to consistently work around the inc/ handling via the (external) lib plugin, but I haven't looked into that deeply.

I have no idea how this should be resolved, possibly by deprecating inc:: style plugins (please not) or by adding the root dir to @INC while loading plugins (also seems ugly), or by supporting built-in functionality like the lib plugin, but special-casing it where necessary.

kentfredric commented 7 years ago

Aka. “Dist::Zilla 6.010 can't load plugins from inc/ under perl 5.26”. As a workaround one can export PERL_USE_UNSAFE_INC=1 in the current shell, but this is really something that dzil should support by itself.

Yeah. There turns out to be no really sane way of handling this other than ensuring "." is reinstated globally sometime before loading the first plugin. Given that by design, you MUST be in your project root for dzil to even work, the typical paranoia about ". might be insecure" is moot.

Note that in some cases dzil handles inc:: modules specially, e.g. by prioritizing them in the authordeps --missing command (see the Dist::Zilla::Util::AuthorDeps::extract_author_deps() function). This prioritization seems to make it impossible to consistently work around the inc/ handling via the (external) lib plugin, but I haven't looked into that deeply.

Yep. Its not possible to pull this trick through a plugin because the design of authordeps eschews loading plugins by configuration, and so there's no step at which authordeps can actually run the magic that makes this happen.

The "seems ugly" concern seems much less significant when you realise you can replace dist.ini with dist.pl and dzil will execute arbitrary code in . as a result that way: https://metacpan.org/pod/Dist::Zilla::MVP::Reader::Perl https://metacpan.org/source/RJBS/Dist-Zilla-6.010/lib/Dist/Zilla/MVP/Reader/Perl.pm#L21

So PR #600 addresses both of these issues by:

  1. Ensuring $dist_root is in @INC before loading dist.ini
  2. Ensuring $dist_root is in @INC before performing --missing checks for Util::AuthorDeps

Pre-existing PR #590 kinda took the same approach as 1, but only did so under dzil testing situations, which just isn't enough to solve this problem for real.