Re: weird do/require search behaviour with @INC refs or EACCES

On Mon, Apr 10, 2017 at 05:59:00PM +0100, Dave Mitchell wrote:
> Now the > rules in their totality seem to be:
> 
>     if the filename is searchable:
>         try against every entry in @INC (both plain and ref)
>             stop if we get a match or EACCES;
> 
>     if the filename is non-searchable:
>         try to load it.
>             if EACCES, stop
>         try against every ref entry in @INC
> 

No-one has commented on this yet.

I'll rephrase the question.

Normally, do and require search @INC for filenames, unless the filename is
of the form /foo, ./foo, ../foo, (aka non-searchable), in which case the
specified file is loaded direclty, without reference to @INC.

In an ideal world (so ignoring for now what perl actually does), if @INC
happens to contain at least one reference (e.g. a code reference, which
allows you to to add "smart" behaviour to @INC), then should do/require on
a non-searchable filename:

a) just attempt to load the specified filename, without reference to @INC;
b) treat the filename as searchable and only try to locate it via the
   subset of @INC consisting of C<grep ref, @INC>;
c) do (a), and if that fails, do (b).

Now, having formed an opinion as to which of (a),(b),(c) is preferable,
I'll tell you what perl actually does. It does (c) - except that if (a)
fails with EACCES, it doesn't continue to try (b).

The test suite only partially tests (c). It expects a non-searchable and
non-loadable file to trigger calling the coderefs in @INC.
It doesn't test whether a non-searchable but directly-loadable file is
loaded directly rather than calling coderefs in @INC.

My feeling is that perl should have implemented (a), but it seems the
intent was to do (b), so we should support that. I think the fact that
perl actually does (c) is an implementation error, and we should probably
change it to (b) at some point in the future. That would mean that prior
to searching @INC, we would have to call get magic on every element in
@INC and see if any entry is SvROK. If any are found, then non-searchable
filenames are treated as searchable instead, and we switch from (a) to (b)
behaviour.

   

-- 
That he said that that that that is is is debatable, is debatable.

• weird do/require search behaviour with @INC refs or EACCES by Dave Mitchell
• Re: weird do/require search behaviour with @INC refs or EACCES by Dave Mitchell
• Re: weird do/require search behaviour with @INC refs or EACCES by demerphq