> On Jan 18, 2017, at 5:23 PM, Olivier Mengué <olivier.men...@gmail.com> 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
