我可以重新测试所有已安装的 CPAN 模块吗？

Posted 2023-03-07

【中文标题】我可以重新测试所有已安装的 CPAN 模块吗？

【英文标题】：Can I retest all installed CPAN modules?

【发布时间】：2018-08-27 05:33:56

【问题描述】：

如果模块 A 依赖于模块 B 并且模块 B 升级，A 可能会因更改而中断。我的想法是在升级B 后重新测试A 和B。

我认为最简单的方法就是重新测试可以重新测试的所有内容：从 CPAN 下载每个已安装的模块并执行其测试脚本。

有没有办法下载重测？

如果没有办法，是否有任何帮助程序/API 以便我可以实现这样的工具？

我基本上需要

查询安装了什么（包括版本号） 下载并解压确切版本 执行测试

【问题讨论】：

cpan -l 为您提供已安装的 cpan 模块和版本的列表，但该列表包括与 Perl 捆绑的模块。如果目标是测试所有内容，那不一定是坏事。 cpanm 实用程序促进了--test-only 模式，并允许您指定版本。

您可能会要求提供模块作者选择从 CPAN 中删除的历史版本，这会变得更加困难。长期以来，CPAN 作者被鼓励通过删除旧版本来保持整洁。我不知道是否仍然鼓励这种做法。

这个问题应该通过应用程序的测试套件和依赖树来解决。只有当您发现您的系统无法正常工作时，您才应该进一步调查。

@Borodin 会破坏cpan/cpanp/cpanm 或prove 等系统工具的依赖项更新怎么办？我更新的模块是什么，因为它们已经过时，但实际上并没有使用？

@DavidO 把你的 cmets 作为答案

【参考方案1】：

核心 Perl 附带的 cpan 工具包括一个 -l 选项，它指示它提供已安装模块的列表。例如，我系统列表中的最后 10 项：

$ cpan -l 2>/dev/null |tail -10
Test2::Event::Encoding  1.302073
Test2::Event::Bail  1.302073
Test2::Event::Exception 1.302073
Test2::Event::Subtest   1.302073
Test2::Event::Skip  1.302073
Test2::Event::Info  1.302073
Test2::Event::Diag  1.302073
Test2::Event::TAP::Version  1.302073
JSON::PP    2.27400_02
JSON::PP::Boolean   undef

如此处所示，您将获得一个模块列表和版本号。有时该工具在 META 中找不到版本，因此将返回 undef 以获取版本号。 CPAN 作者应该注意这些错误，因为它们使那些希望在不编译模块本身的情况下识别版本的工具变得更加困难。

获得模块和版本号后，您可以使用cpanm 工具（由App::cpanm 提供）及其--test-only 选项来拉取特定版本的模块并对其进行测试。您可以像这样请求特定版本：

cpanm Some::Module@0.9990

（仅下拉目标模块的 0.9990 版本）。

事情变得棘手的地方如下：Perl 附带了一堆模块，其中一些还通过 CPAN 接收更新。 cpan -l 工具将列出所有已安装的模块，包括 Perl 附带的模块。

此外，列出的一些模块只是更大分布的一部分。

另一个对您有用的工具是corelist，它自 5.8.9 以来就与 Perl 捆绑在一起。如果你运行这个：

corelist File::Temp

你会得到：“File::Temp was first released with perl v5.6.1”

如果你这样做：

corelist JSON

你会得到：“JSON was not in CORE (or so I think)”

因此，确定您在列表中查看的模块是否是 Perl 附带的模块非常简单。使用您认为合适的信息。

您必须解决的另一件事是如何处理共享依赖项。如果您测试的第一件事是 Moose 升级，那么您将占用一半的 CPAN（这是夸大其词），这会弄脏您测试其他模块的环境。为了减轻这种影响，您有几个选择。一种是利用App::perlbrew 及其lib 选项来设置一次性图书馆空间。这样您就可以在perlbrew lib 和perlbrew use 指定的目标中安装模块及其依赖项，然后在完成后将其丢弃以继续进行下一个库进行测试。

但是，可能有一个更好的解决方案，我对这里的文档不太熟悉：CPAN 烟雾测试人员使用的工具链。如果您希望采用此策略，请参阅CPAN::Testers。冒烟测试人员已经制定了相对轻量级的方法来以自动化的方式下拉和测试模块及其依赖项。

最后，您会遇到的另一个问题是 CPAN 作者决定了哪些版本的模块存在于 CPAN 上，哪些版本会被删除。几年前，CPAN 作者被鼓励通过删除旧版本来保持其 CPAN 存储库的清洁。我不知道是否仍然鼓励这种做法，但这确实意味着您不能指望仍然存在的特定版本号。为了解决这个问题，您可能应该为您在给定时刻安装的所有版本维护自己的 tarball 存储库。 CPAN 模块框架Pinto 有助于保持模块的版本、固定一些不更新，以及其他有用的技巧。

【参考方案2】：

如果您下载并提取分发版B 和cd 到该目录，您可以使用Test::BrewBuild 中的brewbuild 二进制文件（注意：需要Perlbrew 或Berrybrew）和-R 又名--revdep标记以测试B 以及所有需要B 的发行版：

~/repos/Mock-Sub $ brewbuild -R

reverse dependencies: Test::Module::CheckDep::Version, App::RPi::EnvUI, RPi::DigiPot::MCP4XXXX, Devel::Examine::Subs, PSGI::Hector, File::Edit::Portable, Devel::Trace::Subs

Test::Module::CheckDep::Version
5.26.1 :: PASS

App::RPi::EnvUI
5.26.1 :: FAIL

RPi::DigiPot::MCP4XXXX
5.26.1 :: FAIL

Devel::Examine::Subs
5.26.1 :: PASS

PSGI::Hector
5.26.1 :: PASS

File::Edit::Portable
5.26.1 :: PASS

Devel::Trace::Subs
5.26.1 :: PASS

我每次更新我的一个具有反向依赖关系的 CPAN 发行版时都会这样做，因此我不会破坏我的 dists 的任何消费者。