develooper Front page | perl.perl5.porters | Postings from December 2004

Re: [PATCH] Re: getting on a diet

Thread Previous | Thread Next
December 1, 2004 09:18
Re: [PATCH] Re: getting on a diet
Message ID:
"Craig A. Berry" <> wrote:
:In article <>, 
:> 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

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 

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


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About