Project:Perl/Dot-In-INC-Removal

Perl 5.26 makes some significant changes to the Perl Environment, which is expected to affect many users, and at the time of writing this, still has hundreds of bugs open for on various packages, and is expected to need exceptional care from Gentoo Maintainers and end users alike.

Perl Module Loading
Perl has 4 main mechanisms for loading code from external libraries:



All of the above syntax imply looking in an array called, which contains a list of paths to search for the module/file in question to load, in a similar mechanism as how calling commands from the bash shell traverses the contents of the   environment variable searching for an applicable binary.

Prior to Perl 5.26,  had a default last entry of , which behaved similar to how appending the string   to   might work: it allowed Perl to assume that, if the library in question was not available from any of the official installed paths, that the developer who wrote the code might intend to have their code in  , so it falls back to check there also.

This technique was very useful, and was widespread in places where assumptions could be safely made about where the command was being invoked from.

For instance, it was incredibly common to have a project laid out like such:

/ /Makefile.PL  /inc/Module/Install.pm

Where  contained:

use inc::Module::Install;

And due to an established standard of what  would be when calling   it mostly just worked.

It was also incredibly common to have a layout like

/t/ /t/foo.t /t/lib/Bar.pm

Where  contained:

use t::lib::Bar

And this was also reliable.

Similarly, lots of private projects likely utilize this convenience for similar reasons, and it is especially useful for any tool that wants to load extensions/configuration from Perl code by assuming a working directory.

The problem with
Unfortunately, the documentation for  here wasn't entirely clear, and lead the interpretation that

do "File.pm"

Was logically equivalent to

eval qx[cat File.pm];

Wherein it only gave the impression that was the case due to the presence of  in.

Subsequently, a substantial number of people used  under the assumption it had the same semantics as , where the path can always assumed to be relative to