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

I like it.

Are there any caveats for using the same idiom within modules...

use Term::ANSIColor;
() = eval { local @INC = grep !/^\.$/, @INC; require Win32::Console::A
+NSI } if 'MSWin32' eq $^O;
[download]

I'm advocating this idiom to any/all module authors using color in order to improve portability, and I don't want to impact their state negatively.

Hopefully, 'Term::Color' will adopt it into it's synopsis text to further the cause.

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 shmem (Chancellor) on Sep 10, 2016 at 21:22 UTC
Are there any caveats for using the same idiom within modules... I can't see any caveats for using it within modules. It is the modules author's choice to permit or restrict the (arguably unsafe) "." in `@INC`. I'd consider modules relying on "." inside `@INC` to be broken. They shouldn't rely on "." but use something else to get their location, e.g. FindBin or __FILE__ or such - if they are not explicitly chameleonic modules. perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: Mitigating ". in @INC" for optional dependencies
by shmem (Chancellor) on Sep 10, 2016 at 21:22 UTC

Are there any caveats for using the same idiom within modules...

I can't see any caveats for using it within modules. It is the modules author's choice to permit or restrict the (arguably unsafe) "." in @INC. I'd consider modules relying on "." inside @INC to be broken. They shouldn't rely on "." but use something else to get their location, e.g. FindBin or __FILE__ or such - if they are not explicitly chameleonic modules.

perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

[reply]
[d/l]
[select]