t/13-errors.t fails when no '.' in @INC (not ok 26 - require_bad_module_in_once )

[autarch]

Migrated from rt.cpan.org #121443 (status was 'new')

Requestors:

• [email protected] (@kentfredric)

Attachments:

• 0001-Fix-t-13-errors.t-failing-w-o-.-in-INC.patch

From [email protected] (@kentfredric) on 2017-04-29 09:34:50
:

Note: templated response follows

Perl 5.25.11 removes '.' from the default @inc, and this breaks require "t/lib/BadModule.pm" due to not being able to assume ./t/lib/BadModule.pm is
in the @inc load path.

This is not a complete end-of-the-world problem, as Perl provides a temporary
workaround variable (PERL_USE_UNSAFE_INC=1) affected users can set that
restores '.' in @inc temporarily to "just work", and for end users convenience,
CPAN.pm, cpanm, prove and TAP::Harness ( called in make test ) set this
variable, creating an illusion during installation that this problem is not
there

However, this should still be considered a serious issue, as many types of end
users don't get the luxury afforded by the CPAN-and-friends hacks ( vendors,
hand installers, people running perl t/foo.t ), and this workaround is
scheduled to be removed in the future.

And due to aforementioned temporary conveniences and hacks, you should
intentionally defeat said hacks when testing you've fixed this, by explicitly
setting PERL_USE_UNSAFE_INC=0 in your environment prior to running Makefile.PL
and tests, and ensuring to perform said tests on Perl 5.25.11 or newer

Two primary solutions are recommended for tests:

1. Re-organise test dependencies into a dedicated directory such as t/lib and
   load that path into @inc with use lib 't/lib'

2. Rewrite calls to do and require to have either absolute paths ( via
   File::Spec rel2abs ) or have explicit ./ prefixes, both of which disable
   @inc lookup

Both of these suggestions intentionally avoid the easier option of just
reinserting . on purpose, as some proportion of runtime code also is subject
to these cwd-implied bugs, and it is desirable to expose such cases as the
errors they are, not silently suppress their failures

For more details, check
http://blogs.perl.org/users/ryan_voots/2017/04/trials-and-troubles-with-changing-inc.html

---

Raw Error Observed:

perl -Ilib t/13-errors.t
1..26
ok 1 - bad_args
ok 2 - backtrace
ok 3 - read_zero_size
ok 4 - bad_source_callback
ok 5 - bad_escape_flag
ok 6 - error_mode_output
ok 7 - error_in_subrequest
ok 8 - check_error_format
ok 9 - check_exec_not_found
ok 10 - check_exec_not_found_html_format
ok 11 - check_comp_not_found
ok 12 - change_error_format
ok 13 - check_error_format_brief
ok 14 - object_exception
ok 15 - subcomponent_redefined
ok 16 - method_redefined
ok 17 - method_subcomp_conflict
ok 18 - subcomp_bad_name
ok 19 - content_comp_wrong_error
ok 20 - top_level_compilation_error
ok 21 - component_error_handler_false
ok 22 - component_error_Handler_no_upgrade
ok 23 - component_error_handler_false_fatal_mode
ok 24 - component_error_handler_uc_message
ok 25 - use_bad_module
not ok 26 - require_bad_module_in_once

Failed test 'require_bad_module_in_once'

at lib/HTML/Mason/Tests.pm line 553.

Looks like you failed 1 test of 26.

perl -Mlib=. -Ilib t/13-errors.t
1..26
ok 1 - bad_args
ok 2 - backtrace
ok 3 - read_zero_size
ok 4 - bad_source_callback
ok 5 - bad_escape_flag
ok 6 - error_mode_output
ok 7 - error_in_subrequest
ok 8 - check_error_format
ok 9 - check_exec_not_found
ok 10 - check_exec_not_found_html_format
ok 11 - check_comp_not_found
ok 12 - change_error_format
ok 13 - check_error_format_brief
ok 14 - object_exception
ok 15 - subcomponent_redefined
ok 16 - method_redefined
ok 17 - method_subcomp_conflict
ok 18 - subcomp_bad_name
ok 19 - content_comp_wrong_error
ok 20 - top_level_compilation_error
ok 21 - component_error_handler_false
ok 22 - component_error_Handler_no_upgrade
ok 23 - component_error_handler_false_fatal_mode
ok 24 - component_error_handler_uc_message
ok 25 - use_bad_module
ok 26 - require_bad_module_in_once

--

• CPAN [email protected]
• Gentoo Perl Maintainer [email protected] ( [email protected] )

[autarch]

From [email protected] (@kentfredric) on 2017-10-24 04:44:24
:

This transaction appears to have no content