I'd like to avoid the situation where, for example, one of our modules is given an unfortunate name (like "Symbol"), and gets used (and causes problems) because we're in somebody's PERL5LIB.
So if I'm understanding you correctly, you want to avoid the following problem (sample case):
#!/usr/bin/perl use IO::Handle; print "OK\n";
Now, let's say you have a private module "Symbol.pm", which also happens to be used by IO::Handle. So,
$ touch Symbol.pm $ ./891005.pl OK $ PERL5LIB=. ./891005.pl Symbol.pm did not return a true value at /usr/local/perl/5.12.2/lib/5. +12.2/x86_64-linux-thread-multi/IO/Handle.pm line 264. BEGIN failed--compilation aborted at /usr/local/perl/5.12.2/lib/5.12.2 +/x86_64-linux-thread-multi/IO/Handle.pm line 264. Compilation failed in require at ./891005.pl line 3. BEGIN failed--compilation aborted at ./891005.pl line 3.
(In the first case, IO::Handle loads the correct system version of Symbol.pm, while in the latter case, IO::Handle loads your private variant, because it's found first along the search paths.)
I'm not sure, however, how your approach would help here. In other words, you'd get the exact same problem in case you had use lib "."; at the top of the script.
Of course, you could fiddle with the order of the use statements, but that seems very fragile, too (in more complex, real-world scenarios). And if you want to go that route, I don't think there's really any way around having to carefully place boilerplate code in all of your modules... IMHO, choosing an unambiguous namespace for your own code is the better option.
Or is it some other problem you're worried about?
In reply to Re^3: layout/configuration of deployed files
by Eliya
in thread layout/configuration of deployed files
by klassa
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |