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

On 13 April 2017 at 11:57, Dave Mitchell <davem@iabyn.com> wrote:
> 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.

I think I can understand why we ended up with "c" I think. People use
@INC handlers for fallback loading and logging purposes. For instance
I could imagine an @INC handler being used to log any failed requires,
or for maybe generating the file needed on the fly, and then returning
a filehandle to the now created file.

What I think is a bit weird is the part you described where it is
"except if it EACCESS", it seems to me that it would be better to pass
such data into the @INC handlers so they can decide what to do about
it than short-circuiting the callbacks. Maybe we can simple document
that $! will be 0 if the callback is called and there was no error,
and that $! *will* be set if there was no error prior to calling the
callback.

Yves


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

• 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