#p5p finds your lack of failing tests disturbing

[Corion]

5.26 will come with a major change in how Perl builds and runs modules. The current directory will not be in @INC when running Perl programs.

This affects all programs that call require or use and expect files relative to the current directory to be available. Besides plugin systems, any Makefile.PL using for example Module::Install is a likely offender. So far very little has been caught in the net of CPAN testers.

As an example, one of my tests loads Makefile.PL:

use lib '.';
use vars '%module';
require 'Makefile.PL';
# Loaded from Makefile.PL
%module = get_module_info();
my $module = $module{NAME};

This will fail under 5.26+ without the use lib '.'; statement at the top.

I've altered @INC, pray I do not alter it further

If you want to check whether your modules should still work and test OK under the upcoming 5.26 release, I think that the following oneliner should give you a good indication:

perl -M-lib=. Makefile.PL && make && make test

If you run author tests or prefer your tests to be run using prove, you have to take care of prove invoking a fresh Perl:

# Windows syntax:
set PERL5OPT=-M-lib=.
perl Makefile.PL && dmake && prove -bl xt t

@rem Shell syntax:
export PERL5OPT=-M-lib=.
perl Makefile.PL && make && prove -bl xt t

Please test your distributions and release new versions if they need . in @INC. Thanks!

Update: Added call to action and noted where use lib '.' helps.

[shmem]

5.26 will come with a major change in how Perl builds and runs modules. The current directory will not be in @INC when running Perl programs.

This has been overdue. For decades, including the current directory in $PATH for root has been deprecated. A user may carry a firearm (as the NRA propagates) and shoot himself in the foot - or others in the head if possible (well, that's questionable too), and face the consequences. Root (say, the USA military) should never be allowed to do such a thing, because it's not root who faces the consequences, but the whole world.

I don't know how the state of affairs is on that behalf, but perl should make it outright impossible for root to include '.' - the current working directory - in @INC and do should never be able to load and eval a file which doesn't have an absolute path, whilst running under uid 0. Ceterum censeo, -T (taint mode) should be mandatory for scripts/programs running as root.

I must be dreaming... yes, but dreaming is the only way to bear/escape from reality, other than becoming insane.

[RonW]

From the linked message, it seems Mr Fredric is most concerned that the test environments are broken. For my modules, that would be Test::More. Following the examples in the documentation, I rely on Test::More to set @INC appropriately. This appears to work, but I should enhance my tests to make sure that the version I expect to be tested is the one being tested.

He also said:

tests exposing runtime bugs are missing.

I assume this comment is targeted to the testing environment. However, I did try Corion's suggested test to see if any are affected by the change to @INC. Otherwise, none of my modules directly rely on @INC to load anything, so I don't know why I would have any tests for that. Configuration files are located by other means and not loaded with do, require nor use.

[Anonymous Monk]

"As an example, one of my tests loads Makefile.PL "

And you will now pay for your false laziness. There really is no reason to get the name of the module you are testing dynamically.