Indeed... Sorry for not mentioning that.

One of my goals is to keep this code as isolated from everything else as I possibly can. To that end, 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.

I realize that we're in the realm of process problems, here, because developers should know better than to name something that way... On the other hand, anything I can do to make this as bulletproof as possible will only serve to help me in the long run, I think. :-)

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";
[download]

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.
[download]

(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?

I agree that my approach burns the users who execute my scripts, should somebody on my team create a Symbol.pm... However, what (I think) my approach avoids is the case that:

1. somebody sets up PERL5LIB to point to our libs, as a matter of course while setting up their day-to-day working environment (because they intend to run our scripts pretty regularly), and then
2. runs something that's got nothing to do with our scripts, and gets burned because our (badly-named) libraries take precedence

My boilerplate approach only hurts invocations of my scripts; the PERL5LIB approach hurts invocations of all scripts. Potentially.

I do like the idea of using a team-specific namespace... That seems clean, and enables me to leverage PERL5LIB. Thanks!