Re: Supporting a perl without . in @INC

> On Jan 18, 2017, at 5:23 PM, Olivier Mengué <[email protected]> wrote:
> 
> Hi Todd, 
> 
> When I started to seriously code in Perl 10 years ago (going besides scripts to modules and CPAN distributions) I immediately thought: "Having '.' in @INC doesn't seem a good idea. It could be exploited in a similar way as having '.' in $ENV{PATH}". But Perl was already 20 years old, CPAN 10 years old and I thought it was already too late for a fix. So I have started to write test suite code assuming the tests were run from the root of the distribution and that the root of the distribution was in @INC. So I wrote many tests modules in a directory t/lib and teir package names start with "t::lib::" so I can just "use t::lib::TestModule". And I'm not alone using that style: http://grep.cpan.me/?q=t%3A%3Alib%3A%3A <http://grep.cpan.me/?q=t::lib::>

Sure. Even more of a problem is "use inc::Module::Install;"

> So I don't think your major break can avoid a major effort to patch CPAN and DarkPAN code. Either with new fixed CPAN releases or with distroprefs.

Others have claimed this. I don't think it's as hopeless as you say. Much of what I'm suggesting has already been implemented via patches in the perl that cPanel ships with little or no fallout. 

> > What at this point I feel is lacking is agreement and/or discussion that the above is the correct approach to solving this problem.
> 
> A few questions:
> - If the CPAN clients and the modules installer will get PERL_USE_UNSAFE_INC=1 built-in, I don't see how I will be able build an environment to test my CPAN distributions that doesn't have . in @INC at all. So it seems that in the name of preserving backwards compatibility you are stopping the move towards your long term goal. Or did I miss something?

My initial goal is to get . out of @INC in production environments. The build option -Ddefault_inc_excludes_dot provides this functionality. 

The one place that seems to be incurably broken with its dependance on . in @INC is the build/test/install system. I am not trying to fix that system at this time though I would encourage best practices going forward to discourage dependance on . in @INC.

> - If the testsuite runs with PERL_USE_UNSAFE_INC=1, but once installed the runtime environment is not the same, issues with @INC will just be hidden in the test run to be discovered at runtime. Adding "use lib '.';" at the top of each test script will hide issues in the same way. So what's the point of running the testsuite if it can't show issues?

For the most part that has not shown to be true. In the distro of RPMs that I maintain with about 1000 RPMs and the distro Debian maintains with many more, we have not seen any valid dependance on . in @INC once the modules are installed.

> But I have another proposal. Instead of modifying CPAN clients, builders and App::Prove to inject '.' into @INC, what about instead injecting in @INC the *absolute path of the root of the distribution* being configured/built/tested/installed? I think that this would considerably reduce the number of side effects and it would help to really isolate runtime code that relies on '.' being in @INC (assuming that code is covered by a testsuite).


Technically perl -Mblib does something very similar to this already. How would /home/cpan/Moo instead of . be a safer or saner path? Keep in mind nothing that has been done so far has discouraged require/use from supporting relative paths. We've only taken it out of the default.

Thanks for your thoughts!

Todd