develooper Front page | perl.perl5.porters | Postings from October 2003

mp1 and %INC (was Re: 5.8.2 perldelta)

From:
Geoffrey Young
Date:
October 30, 2003 07:30
Subject:
mp1 and %INC (was Re: 5.8.2 perldelta)
Message ID:
3FA12E8B.30702@modperlcookbook.org


Stas Bekman wrote:
> Here is the problem. If a module fails to load once it must not be 
> blacklisted. The test demonstrates how a module may fail if loaded from 
> the wrong directory, but then is supposed to succeed if moved to a 
> different directory.

this is somewhat addressed in the original thread:

http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-09/msg01486.html
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-09/msg01518.html

I think Rick makes a good point - in a persistent environment like mod_perl 
the file contents (or location) ought not to change during production, and 
for development we have the Apache::Reload/PerlFreshRestart options.  and, 
as it turns out, it's PerlFreshRestart that is the culprit here - it 
explicitly sets each %INC entry to undef to allow for a reload, which now is 
a problem, since undef is now the trigger for a bad attempt.

from rick's patch email:

"The following patch arranges for failures to be cached in %INC as undef
values (success is still cached as filename).  I think this should be OK;
I'm not aware of any other meaning for undef values in %INC (and neither is
the test suite)."

I think it would help mod_perl (and possibly others) is the trigger were 
something other than undef - a specific marker could blacklist the module, 
while undef could continue to work as before and allow for a reload.

however, if perl isn't interested in changing current behavior, here is a 
patch that compensates for the changes within mod_perl.

--Geoff



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About