Diddling @INC, order of entries in it
David Cantrell
david at cantrell.org.uk
Wed Aug 1 17:24:11 BST 2007
[ 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.
--
David Cantrell | Reality Engineer, Ministry of Information
I hate baby seals. They get asked to all the best clubs.
More information about the london.pm
mailing list