Hmm- looks like the answer is this-- perl maintains one @INC array per perl interpreter invocation, which normally is sufficient because each program run will load its own copy of the interpreter. However, under Apache/Mod_Perl, only one copy of the interpreter is running, and so each local path pushed onto the @INC array is shared between all the running scripts. What order is dependant on how apache loaded the virtual hosts, etc. So normally this would not be a problem but in the case of mod_perl it is.
Now I know why its happening but I'm not sure what to do about it. Has this bitten anyone else? John On Thursday 05 September 2002 07:32 am, Brat Wizard spewed into the ether: > Hi there Josh (and everybody) > > I've got a strange problem-- snip] > So the bottom line cause of my weirdness is that I'm loading up modules > (I'm guessing at random, or perhaps by @INC order, I'm not sure) from the > wrong code tree (library directory). And in my DEV version, which should be > using the NEW module under test, its ACTUALLY using the OLD version in > production. There is NO OTHER WAY to get the production module, and > printing out the @INC array confirms that both paths are in there. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
