Re^2: Mitigating ". in @INC" for optional dependencies

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.

Comment on Re^2: Mitigating ". in @INC" for optional dependencies Download Code

Replies are listed 'Best First'.
Re^3: Mitigating ". in @INC" for optional dependencies by Corion (Patriarch) on Sep 11, 2016 at 05:57 UTC
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]

Replies are listed 'Best First'.

Re^3: Mitigating ". in @INC" for optional dependencies
by Corion (Patriarch) on Sep 11, 2016 at 05:57 UTC

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]