Diddling @INC, order of entries in it

Dan Rowles d.rowles at outcometechnologies.com
Wed Aug 1 18:08:25 BST 2007


How about you override the require method? Or possibly the "do" method 
instead?

Dan



David Cantrell wrote:
> [ Adriano Ferreira CCed so he knows just what kind of insanity I'm
>   inflicting on his code :-) ]
> 
> I'm hacking around in the guts of Devel::Hide, trying to add a facility
> to make it hide modules from child processes created by fork-and-exec,
> so eg ...
> 
>     use Devel::Hide qw(-fromchildren Foo::Bar);
> 
>     system("perl -MFoo::Bar ..."); # Foo::Bar is unavailable here
> 
> D::H works by putting a coderef into @INC, which checks what you're
> trying to load, and which fails as appropriate.
> 
> I have it so that if you pass the magic value '-fromchildren' to D::H's
> import() like above, it puts MDevel::Hide=Foo::Bar into PERL5OPT.  And it
> works.
> 
> It works right up until the child process does this ...
> 
>     use lib 'my/secret/stash/of/modules';
>     use Foo::Bar;
> 
> cos then, 'my/secret/stash/of/modules' gets stuffed into @INC *before*
> the coderef, and so if Foo::Bar can be found under there, it gets
> loaded.  I don't want this to happen, partly because it makes writing
> the tests (which start with 'use lib "t"') for the new bits of code in
> Devel::Hide a bit annoying.
> 
> Can anyone think of a nifty way around this?  The only one I can think
> of is to have Devel::Hide mess around in the guts of lib.pm and change
> them so that the reference to Devel::Hide's magic subroutine *always*
> comes first.
> 
> If I *do* have to mess around in lib's guts, I imagine what I want to
> do is replace its import() with one that goes ...
> 
> sub import {
>     # call the original import(), save its return value
>     search @INC and move my magic subroutine to the beginning
>     # return the original import()'s return value
> }
> 
> And indeed *should* I be trying to subvert 'use lib' like this?  I can
> make the tests pass by putting Mlib=t in the right place in PERL5OPT, of
> course, so perhaps that's the better choice.
> 

-- 
Dan Rowles
Outcome Technologies Ltd
BUPA House, 15-19 Bloomsbury Way, London WC1A 2BA
Registered in England, No: 3829851


More information about the london.pm mailing list