Question

在.pl或.pm具有use lib或unshift @INC的情况下测试Perl代码时，在覆盖Perl库时遇到一些困难，我的问题是：

在生产代码中使用use lib或unshift @INC是一个不好的主意，因为它们很难测试吗？ prove -lvr也无法覆盖它们。

代码test.pl

push @INC, '/push/inc/lowest_priority';
use lib "/top/priority/use/lib/second_priority";
unshift @INC, "/unshift/inc/lib/first_priority";
foreach my $inc (@INC){
    print "INC=>$inc\n";
}

设置perl环境

export PERL5LIB=/export/PERL5LIB/env/lib:$PERL5LIB

perl -I/cmd/Iinclude/lib/ test.pl的输出

INC=>/unshift/inc/lib/first_priority
INC=>/top/priority/use/lib/second_priority
INC=>/cmd/Iinclude/lib/
INC=>/export/PERL5LIB/env/lib
INC=>/usr/local/lib64/perl5
INC=>/usr/local/share/perl5
INC=>/usr/lib64/perl5/vendor_perl
INC=>/usr/share/perl5/vendor_perl
INC=>/usr/lib64/perl5
INC=>/usr/share/perl5
INC=>/push/inc/lowest_priority

Answer 1

除非没有其他选择，否则我不会对路径进行硬编码。

通常，您不想以其他某种方式对可以提供给程序的内容进行硬编码，以便它可以响应所处的任何环境，而不仅是对开发环境的响应。这些环境之一就是您的测试环境。

您可以从程序外部设置库搜索路径，这使其更加灵活。

并且，由于您对它们进行了硬编码并在运行时将其添加，因此它们将在您之前设置的所有内容之后出现。这是您的设置中发生的情况：

您从默认的@INC开始。
您开始“运行”程序，然后开始编译阶段。在执行运行时语句之前，它将编译整个程序。
在编译时，它遇到use lib并立即执行该编译指示。现在/top/priority/use/lib/second_priority在@INC的开头。
在其余的编译阶段，/top/priority/use/lib/second_priority是@INC中的第一件事。这就是随后的use调用将在其中寻找内容的地方。
编译阶段完成，程序过渡到运行阶段。
它遇到push并执行它。现在/push/inc/lowest_priority是@INC的最后一个元素。
因为编译阶段处理了编译指示，所以它跳过了use lib。
它遇到unshift并执行它。现在/unshift/inc/lib/first_priority是@INC中的第一项。
随后的require调用（运行时功能）将首先在/unshift/inc/lib/first_priority中出现。

我不知道您期望在哪里找到期望加载的库，但是您必须提供它的完整路径。在 lib / 下可能还有其他重要的目录，您可能没有考虑。

Answer 2

我可能会误解您的问题，但是local::lib允许您“手动”调整模块路径。您应该能够使用它来控制用于测试环境的路径。

PERL5LIB，@ INC和库优先级进行测试

2 个答案: