Tests fail when no '.' in @INC about template2

[xsawyerx]

Further investigation tells me the implications of this test failure can break runtime code, as the failing logic is in _load_compiled:

sub _load_compiled {
    my ($self, $file) = @_;

    # load compiled template via require();  we zap any
    # %INC entry to ensure it is reloaded (we don't
    # want 1 returned by require() to say it's in memory)
    delete $INC{ $file };
    eval { $compiled = require $file; };
    return $@

This means that when a consumer of Template::Provider ends up with a relative path on Perl 5.26+, Template::Provider will be broken.

But of course, only broken in production, because PERL_USE_UNSAFE_INC=1 being present in the environment within Test::Harness and CPAN installers will hide this during install and test phases.

My first stab that seems to satisfy tests with PERL_USE_UNSAFE_INC=0 is as follows, but I'm not sure if its the right approach.

diff --git a/lib/Template/Provider.pm b/lib/Template/Provider.pm
index 6ecb2453..3ae72b03 100644
--- a/lib/Template/Provider.pm
+++ b/lib/Template/Provider.pm
@@ -564,11 +564,12 @@ sub _load_compiled {
     my ($self, $file) = @_;
     my $compiled;
 
+    my $fpath = File::Spec->rel2abs($file);
     # load compiled template via require();  we zap any
     # %INC entry to ensure it is reloaded (we don't
     # want 1 returned by require() to say it's in memory)
-    delete $INC{ $file };
-    eval { $compiled = require $file; };
+    delete $INC{ $fpath };
+    eval { $compiled = require $fpath; };
     return $@
         ? $self->error("compiled template $compiled: $@")
         : $compiled;

[xsawyerx]

Attached is a (slightly improved) patch, but I'm still not 100% on it. This is an excellent time to be cautious because the code this patch modifies has in effect been there since Commit #0 ... Which was forged according to git merely 3 months after Perl 5.6.0 was released.

[Instead of attaching, I've submitted this as PR #79.]

[xsawyerx]

On further consultation, it seems my first guess was actually the best way to do this, and here's an updated patch with inline comments that will help persuade anyone else who got distracted like I did with imagined problems.

[Instead of attaching, I've submitted this as PR #80]

[atoomic]

Seems like #80 is more conservative and keeping the spirit of the original code, whereas #79 is suggesting a different approach by using 'do', which could come with its own risk.

I see no objections to one approach or the other, I've a preference for the 'do' one too.
'do' as 'require' will populate %INC, but would have the advantage to run the code more than once.

> echo "print 42" > a.pl
> perl -e 'do "./a.pl"; print keys %INC; do "./a.pl"'
42./a.pl42
> perl -e 'require "./a.pl"; print keys %INC; require "./a.pl"'
42./a.pl

@xsawyerx could you confirm your preference for #79 ?

[atoomic]

#79 was rejected as it contains two ideas:

• the fix for dot in INC
• do instead of eval require which is a behavior change, this should be a different discussion to #179

We can close this case with the merge of #80

[xsawyerx]

@atoomic I don't have a preference. These were not done by me, but by @kentfredric. I have merely copied the tickets over from RT to here, so they could be more easily reviewed.