1

我试图更好地理解我可以使用 什么，并在 key规范CPAN::Meta::Spec中遇到以下句子：file

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

这句话对我来说就像一个能够META.*使用文件路径而不是*.pm. 因此，使用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.*文件。

  1. 这样的META.*外观如何，它包含什么？name只有和之类的东西version，这也是原生 Perl 包可能提供的东西？license或者像and之类的其他东西keyword，也许除了依赖关系之外的所有东西？

  2. CPAN 客户如何处理这种情况？META.*显然不是 Perl 包本身，我看不出它是如何用来生成它的。那么最终实际安装在系统中的是什么？是否有一些额外的机制以某种方式生成包？

  3. 如何提供META.*而不是*.pm兼容密钥version和以下限制：

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

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

感谢您的澄清！

4

1 回答 1

1

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

于 2019-02-03T17:54:13.177 回答