Aaah - now I understand the situation a bit better.
Please, don't do that from within your module. If the main script has (or leaves) . in @INC, it is not up to your module to question that. At program start, you could, in your main program, either convert . to an absolute path relative to the program, or the current directory, or remove it alltogether from @INC, but having modules implement their own handling makes only for a confusing situation where one module loads and the other doesn't, because they use different module loaders, instead of using require together with @INC as set up by the main program.
If you decide to go the route of (locally) filtering @INC, at least output a warning if you remove . from @INC and loading the module fails.
In reply to Re^3: Mitigating ". in @INC" for optional dependencies
by Corion
in thread Mitigating ". in @INC" for optional dependencies
by Wyrdweaver
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |