我正在研究如何打包我的一些Perl应用程序并更好地管理它们的依赖关系,以使我和我的客户更轻松地进行分发,这很可能根本不包括上传到CPAN。相反,我会在必要时提供自定义存储库,或者更有可能提供对Subversion等SCM的访问。
CPAN::Meta::Spec似乎提供了我需要描述的应用程序,它们的依赖项以及从何处获取它们的信息,但是我想知道的是必备条件的详细程度。 The spec包含以下句子:
关系集必须指定为程序包名称到版本范围的映射。
需要的软件包对于我的需求而言似乎有点太低了,我宁愿需要发行版。 Maven和Gradle之类的水平工具(据我所知)在例如Apache Commons Lang与Apache Commons IO等,而不是像org.apache.commons.lang3.AnnotationUtils
或org.apache.commons.io.ByteOrderMark
这样的单个类。 OTOH,文档中的示例包含以下几行:
requires => {
'perl' => '5.006',
'File::Spec' => '0.86',
'JSON' => '2.16',
},
在我看来,包含perl
的行不像是一个包,我在系统上的任何地方都找不到package perl
或perl.pm
。在我看来,这种处理方式与示例中的其他内容有所不同。
我有一个系统范围的文件夹,其中包含一些实用程序包,在我看来似乎可以与某些抽象perl
相提并论。该文件夹应被定义为一个发行版,并为该文件夹中的所有软件包维护一个版本号,因此应允许其他应用require
进行整件事。如果我正确理解了文档,则不仅需要在文件夹中创建META.yml
,还需要创建一些其他信息,例如sysutils.pm
包含package sysutils;
并定义了一些版本。
是否有某种方法可以避免创建该文件,而实际上仅require
仅分发本身?
META.yml
已经包含一个名称和版本,因此从理论上看来require
可以包含一些抽象的东西。我看不到需要添加一个额外的.pm
文件来代表发行版本身,而只允许require
工作。就我而言,它不会包含任何业务逻辑。
谢谢!
答案 0 :(得分:3)
那真的不是您想要的。要预-REQ你真正的需要的。因此,例如,如果您需要File::Spec
,那就是您需要的,而不管它是来自perl内核还是来自单独的CPAN发行版。
我已经看到某些模块从CPAN移到核心,反之亦然的情况。通过直接要求该模块,您不必仅因为您所依赖的人更改了其分发方法就可以发布依赖发行版的新版本。
我也看到其中的某些模块被从它们的原始分布,当它被确定它们作为单独模块有价值分裂情况。根据模块意味着你在一堆其它模块不再拖动一个简单的依赖关系。
您正在寻找的或多或少类似于Task::*
模块。在大多数情况下,没有真正的逻辑,只是更多依赖项的列表。
答案 1 :(得分:0)
Perl依赖系统完全在多个级别上使用程序包名称。上载CPAN分发时,PAUSE会为其中的每个程序包建立索引,PAUSE还会检查上载者是否对该程序包具有permissions,并且该程序包具有比currently indexed package更高的版本。这些检查都不关心整个分布(尽管索引器确实在该级别进行其他检查)。
然后,当CPAN客户端看到依赖性时,或者您告诉它安装某些东西时,它将检查该软件包名称的索引,从而告诉它要安装的发行版。如果它取决于某个版本,则将在安装时根据该软件包中声明的$VERSION
进行检查。而一旦安装了发行版,就不再跟踪其“版本”。分发级别几乎完全没有意义,只不过它最终是为了满足这些依赖性而下载并安装的。这很重要,因为模块可以并且确实可以在发行版之间移动,并保持其版本增量,并且软件包索引始终会告诉您哪个发行版可以获得所需的版本。
您注意到,perl
依赖性很奇怪。这是一个永远存在的特殊情况,作为约定声明您需要的Perl版本,您声明运行时要求为perl
。它不是索引模块,每个CPAN客户端和CPAN元数据的其他使用者在特殊情况下要么忽略它,要么将其视为Perl的最低版本,而不是可以安装的版本。通常无法将其扩展到适用于发行版,并且尝试这样做是一个坏主意。
作为附加说明,CPAN元规范是CPAN发行版中包含的名为META.json
的文件的规范(META.yml
是旧版本),但是此文件由您的创作工具自动生成。尽管您可能需要创作工具手动添加某些键(在这种情况下,阅读规范很重要),包括prereqs
,但决不能手动创建它。有关如何为各种创作工具指定依赖项的信息,请参见neilb's blog post,然后将其转换为生成的META文件,以及通常如何使用cpanfiles指定依赖项。