结构“提供”的关键“文件”如何与“CPAN::Meta::Spec”的“META.*”一起使用？答案

【问题标题】：How does the key "file" of the structure "provides" work with "META.*" for "CPAN::Meta::Spec"?结构“提供”的关键“文件”如何与“CPAN::Meta::Spec”的“META.*”一起使用？
【发布时间】：2019-06-27 11:31:44
【问题描述】：

我正在尝试better understand 什么I could use CPAN::Meta::Spec 并在spec 中遇到以下句子作为键file：

[...]到包含或生成包的文件。它可以作为 META.yml 或 META.json 给出来声明一个用于索引的包，而不需要 *.pm。

这句话对我来说就像一个能够使用文件路径而不是*.pm 在配置中直接指定一些META.*。因此使用it 的措辞，这显然与前面提到的路径相关联。很像下面的例子：

provides => {
  'Foo::Bar' => {
    file    => 'lib/Foo/Bar.pm',
    version => '0.27_02'
  },
  'Foo::Bar2' => {
    file    => 'lib/Foo/Bar2.yml', <-- META.yml?
  },
  'Foo::Bar3' => {
    file    => 'lib/Foo/Bar3.json', <-- META.json?
    version => '0.3'
  }

因此，虽然 Foo/Bar2.pm 和 Foo/Bar3.pm 可能存在于分发中，但它们并未明确定义，而是使用 META.* 文件隐式定义。

这样的META.* 是什么样子的，它包含什么？只有像 name 和 version 这样的东西，这也是原生 Perl 包可能提供的东西？或者像license 和keyword 之类的附加内容，可能除了依赖项之外的所有内容？
CPAN 客户端如何处理此类情况？ META.* 显然不是 Perl 包本身，我看不出它是如何用来生成它的。那么最终实际安装在系统中的是什么？是否有一些额外的机制以某种方式生成包？
如何提供 META.* 而不是 *.pm 与密钥 version 和以下限制兼容：

[...]如果包没有 $VERSION，则必须省略此字段。

在这种情况下，META.* 是否算作包含$VERSION 的包？还是期望最终以某种方式生成包并且必须具有$VERSION，并且只要不生成包，就可以简单地使用META.*的版本？

感谢您的澄清！

【问题讨论】：

创建一个聊天，并标记我。我可能对你的真正问题有一个想法。我现在无法进入它。

标签： perl dependencies dependency-management cpan metacpan

【解决方案1】：

provides 元数据是发行版提供的软件包列表，主要供 PAUSE 索引器使用，但也可由分析工具使用。如果存在，PAUSE 将不会检查您的文件中的软件包及其版本，但会信任 provides。对于分发中的每个包，它必须列出包所在的文件，以及包的版本（如果有的话）。由于这是“覆盖”，因此不需要与现实相匹配，但除非您正在做一些非常奇怪的事情，否则它应该这样做。如果您有一个没有关联文件的包，那么将文件设置为META.yml 或META.json 的能力只是一个后备方案；您需要这样做是非常罕见的，它对META.json 或META.yml 没有额外的要求，除非它们应该存在。与往常一样，在实现中，此元数据始终设置在分发包中的META.json 和META.yml 中。

【讨论】：