in reply to Mitigating ". in @INC" for optional dependencies

Have you considered simply writing your Makefile.PL manually if your release framework does not cater to your specific module's needs?

If your main script puts . into @INC, it's not the purpose of your modules to second guess your main script.

What actual problem are you trying to solve that . not being in @INC causes? I don't see how your scripts would behave differently whether @INC contains the current directory or not.

Replies are listed 'Best First'.
Re^2: Mitigating ". in @INC" for optional dependencies
by Wyrdweaver (Beadle) on Sep 10, 2016 at 19:40 UTC

    Apologies to @Corion... the code, as originally posted, could be seen as pursuing the opposite of my actual goal. The code should have read ... 

    no lib q{.}
...

    [download]
    ... it has now been corrected.

    I'm trying to mitigate against the fact that '.' is included by default in @INC, and therefore a module could be "snuck in" if the optional dependency is not installed on the system.

    I just want to avoid looking in '.' when loading the optional module.

[reply]
[d/l]

      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.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom