"Craig A. Berry" <[EMAIL PROTECTED]> wrote: :In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] :wrote: :> I think it would set a bad precedent to have a core module ignoring :> changes affecting @INC. : :It would only ignore run-time changes to @INC or run-time changes to :the current working directory that render relative paths in the :existing @INC useless.
Yes, but if you've put a relative directory in @INC it should stay relative when the CWD changes. Note that there may be good reasons for doing this, for example in situations where you are substantially changing the environment in which the program runs, such as chroot(), umount() or simply unlink(). : Camel 3 p. 300 says, "Since C<use> loads :modules at compile time, any modifications to C<@INC> need to occur at :compile time as well." The Camel may be misleading: there may be many "compile times" during the running of a program. : Since Config has moved part of its load process :from compile time to run time, it seems to me it's responsible for :making sure it finds its own private pieces at run time as if it had :all happened at compile time. In general, I would not expect any onus on a module writer to ensure that all subsidiary modules it needs be resolved when their module is first compiled. It should be assumed perfectly reasonable to write any module to defer loading of subsidiary modules to the point they are needed. Therefore I conclude that it is in general unsafe to put relative paths in @INC except where you specifically know it is appropriate, either because you know the script will not chdir, or because you want the paths to stay relative even when it does. :> Maybe it would be possible to replace ./lib :> with its fully-qualified equivalent? That has the benefit of expressing :> the intent: to add *this* lib directory to @INC. : :Yes, we could do that, or we could just do what the Unix build does and :sprinkle -I../lib everywhere. I have a patch in progress to do the :latter. By the above reasoning, we should rather be fixing the Unix build to avoid both ./lib and ../lib. Whether that is practical to achieve at this time is a separate question, of course. However I suspect that such a change would be a large enough perturbation of the build system that it would be unlikely to go into the maintenance branch, so I guess it is worth continuing with your current patch in any case. Hugo
