As the solution is buried fairly deeply in this thread, I've provided links here.

++choroba provided the basic information for the solution: "Re^5: require() @INC hooks problem [non-Moose]".

How I implemented the solution: "Re^6: require() @INC hooks problem [non-Moose]".

And again, many thanks to ++choroba. I had spent many hours, on and off since before Christmas, trying to nut this one out.

        my sub for_inc {
            my ($coderef, $filename) = @_;
            return \$source
        };

        my $for_inc_ref = \&for_inc;
[download]

instead please try

 
my $for_inc_ref = sub 
    {
        my ($coderef, $filename) = @_;
        return \$source
    };
[download]

unfortunately I can't test right now.

Thanks for guessing; if nothing else, it eliminates possibilities.

In earlier versions of the code, I did have what you suggest, as well as push @INC, sub { ... };. I tried both of those with and without the my ($coderef, $filename) = @_;.

— Ken

> I've also tried various versions where use namespace::autoclean; and/or __PACKAGE__->meta->make_immutable; were excluded just in case that made any difference: it didn't.

well ... but still with Moose?

G'day Rolf,

Short answer: no.

The module that I'm working on is part of a series, all of which use the Moose framework. The dynamic_require() idea seemed like a nice thing to have; but, at the end of the day, if it doesn't work with Moose for some reason, I can live without it.

In earlier testing with the real module, I did find that hard-coding the $source into a test file worked fine, even with multiple instances (e.g. the source generated with "Test1" and "Test2").

The problem does seem to be somewhere in dynamic_require(); however, I've no idea where that might be. The fact that it works once, but not twice, is just very puzzling.

— Ken

Short answer: I'm willing to look into it as soon as Moose is not involved in your SSCCE ! :)

(Moose doesn't qualify as "short" or "self contained" in my book ;-)

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

Why are you installing multiple hooks?

Why do you even need a hook if your require happens right away?

I'm puzzled ...

"I understand now what's happening, ..."

That's great. In "Re^6: require() @INC hooks problem [non-Moose]", I wrote: "The mechanism behind this is a mystery to me. Why is it calling the subroutine with all the previous CODEREF values then the newly created CODEREF?" Perhaps you would share your understanding.

"... but I have trouble getting what your intention is... (???)"

The subclasses, in this instance, are to be used for exception objects. There are multiple ways to handle this; this seemed like a handy way to do it. It follows the DRY principle and abstracts any required code to a single statement.

"Why are you installing multiple hooks?"

That's not actually a requirement at the present; although, I can see that it might be useful as code development progresses. The problem (1st hook working; 2nd hook not working) came up while testing. I don't like loose ends, or sweeping problems under the carpet, so I followed up with an investigation into this.

"Why do you even need a hook if your require happens right away?"

Technically, it's not a requirement; it's just, as I said above, "a handy way to do it". I don't need to write individual X/Y/Z.pm modules for require X::Y::Z statements.

"I'm puzzled ..."

Hopefully, less so now. :-)

— Ken

First things first

> > "Why do you even need a hook if your require happens right away?"

a require is basically a

• load file into string
• eval string
• update %INC to avoid further loads
instead of a hook you can simply eval your template and update %INC.

> I don't need to write individual X/Y/Z.pm modules for require X::Y::Z statements.

you don't need to save them to a file.

Just eval the code and update %INC

> > "Why are you installing multiple hooks?"

A hook is an abstraction of a directory path in @INC, which are searched sequentially.

Either a path includes a requested module (SUCCESS) or the next is searched (FAIL)

But your hook in the OP always returned the same code of the first module, no matter which module was requested. It should have signaled a FAIL, to allow the next path/hook to handle the request.

And each of your hooks is only returning one file, which is an overkill and "littering" @INC with hooks.

> Perhaps you would share your understanding.

If you want you can look into the working example I wrote for HaukeX' webperl project:

[WEBPERL] dynamically importing non-bundled modules via http

you just have to adapt the coderef $fetch and %INC_FETCH to your needs.

BUT as I said, you don't even need hooks if you eval those modules right away.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}