【发布时间】:2019-06-26 18:31:18
【问题描述】:
这与关于CPAN::Meta::Spec 的former question 有关,它似乎不是为我认为可以使用它而设计的。
我的用例
我有不同的 Perl 应用程序,它们本身包含很多包,这取决于一些自制的系统范围的实用程序,当然还有第 3 方包。这些应用程序可能会根据运行时配置提供不同的功能,并且根据这些功能,依赖关系是不同的。此外,如果自动化测试可用,那么这些也可能会引入依赖关系,在最新示例中,这些依赖关系在 Windows 上的 ActiveState Perl 5.22 中默认可用,而在 Ubuntu 16.04 上则需要使用 APT 安装。
我自己的应用程序和实用程序是使用 Subversion 维护的,并且这些存储库也至少部分向客户公开。第三方包最好由操作系统的包管理器维护,如 APT 或 Perl 发行版,如 Windows 上 ActiveState Perl 的 PPM。只有当某些依赖项不可用时,CPAN 才会发挥作用。
我想要实现的目标...
...以一种允许我区分的方式描述我的应用程序和系统范围的实用程序及其依赖项,例如运行时来自开发或测试,并且能够区分可选功能及其依赖项。此外,我想维护一些存储库,例如可以下载我自己的应用程序和系统范围的实用程序。
我不想要的……
...是在多个地方维护我在某处使用的每个单独的包,因为这对我来说没有多大意义。 APT 不一定要安装单独的 Perl 包,而是一些包含多个这些包的更高级别的发行版,例如一个完整的应用程序。如果引入了依赖项,开发人员无论如何都需要检查它们是否在所有感兴趣的平台上都可用,不一定是这种情况,以及它们是如何在每个平台上分布的,例如APT、PPM 或 CPAN。因此,如果不检查这些包是如何分布在哪个平台上的,就不能轻易地引入对单个包的依赖。因此,管理包级别之上的依赖项似乎足以满足我的需求,无论如何,这主要是在平台上维护的。
此外,这就是例如Maven 和 Gradle 工作:不依赖于单独的类,如 org.apache.commons.lang3.AnnotationUtils 或 org.apache.commons.io.ByteOrderMark,而是依赖于包含这些类的发行版,如某些特定版本中的 Apache Commons Lang 和 Apache Commons IO。虽然最终在某个类中导入了各个类,但项目描述及其依赖项本身并不包含该级别的详细信息。我不明白为什么我应该深入研究 Perl,如果它非常适用于 Java,如果我需要在分发级别检查是否可以完全满足 Perl 依赖项。
我需要什么
所以,我需要一些规范/DSL 来描述我的项目,其中包含一些名称、版本号、它的依赖项以及很可能从哪里获取内容的不同存储库。这样的存储库将是我自己的 SVN 存储库或 APT 或 PPM 之类的概念,如果有人决定托管此类存储库,最好甚至为这些存储库提供额外的存储库。最后,应该使用像 Ansible 这样的工具来安装我的一些应用程序,同时能够根据每个应用程序/项目的规范使用插件或其他工具或其他工具自动处理依赖关系。
到目前为止我发现了什么
对于 Perl,这让我想到了 cpanm、cpanfile 和 CPAN::Meta::Spec,它们都能够区分运行时和测试,支持可选功能等。后者甚至可以为不同的 repos 建模。但两者似乎都只支持对包的依赖,而不是一些更高的分发级别。不过,也许可以使用一些充当分发占位符的包来解决此问题。例如。通过创建包含package sysutils; 的sysutils.pm 并仅定义某些版本。然后,应用程序可以使用上述格式依赖该包。
目前公认的缺点
但是人们例如建议不要手动编写CPAN::Meta::Spec,而是使用一些build and authoring tools。问题在于,链接的博客文章本身或other sources 认为某些/大多数已弃用,有些示例甚至最终仅向这些工具提供手动编写的CPAN::Meta::Spec。如果不是,他们有时只是期望CPAN::Meta::Spec 的信息采用某种自定义配置格式,这似乎不如规范本身定义得那么好。那么为什么要使用这些工具而不是手动编写规范呢?
即使CPAN::Meta::Spec 本身似乎也有问题,因为最新版本 2 似乎更喜欢 JSON 出于某种未记录的原因。当然,对于手动编写和维护该规范来说,这是一个糟糕的决定,因为 JSON 缺少 cmets,在我看来,这对于人类维护的任何类型的描述都是不可行的。
问题
那么,我可以使用哪种格式/规范来手动描述一些使用某些名称和版本的抽象分发,包括它的可选功能和依赖项?
CPAN::Meta::Spec似乎已经完成了几乎所有的事情,只是目前对我来说,包级别的依赖关系似乎太低了。应该使用哪个工具来解决基于之前规范的依赖关系,并支持 APT、PPM 和 SVN 等依赖关系的不同 source-repos?
1234563 /p>
感谢您的建议!
【问题讨论】:
-
“一些/大多数被认为已弃用” - 这无关紧要。不要使用 Module::Build 或 Module::Install,为它们提供信息是为了让仍在使用它们的人受益。还有许多其他选项正在积极使用和维护。
-
真正的问题是您希望如何使用此元数据。 CPAN::Meta::Spec 和 META.json 旨在供 PAUSE 和 CPAN 安装程序使用。如果您不会使用 CPAN 安装程序,那么您没有理由使用它,尽管您当然可以将其用作灵感。另一方面,cpanfile 是一种为指定 Perl 模块依赖关系而设计的格式,任何使用 Module::CPANfile 都可以读取它,因此我之前推荐它。
-
此外,cpanm(仅限开发版本)和 carton 识别一些选项,您可以将其应用于 cpanfile 要求以从特定 URL 安装,这可能很有用。 The carton docs mention it 和我有一个 open pull request 来为 cpanm 记录它。
-
Re "除了包级别的依赖关系之外,CPAN::Meta::Spec 似乎已经实现了几乎所有的可能性。",你错了。 CPAN::Meta::Spec 完全是关于定义对包的依赖。问题是,它是关于定义对 Perl (CPAN) 包的依赖关系。您显然希望依赖于其他类型的包。这给我们带来了一个关键问题:你在谈论什么样的包?如果您不指定什么系统,我们无法告诉您如何在系统中定义可选依赖项。
-
@Grinnz
dist和url实际上看起来很有趣。您是否知道目前对APT或PPM等包管理器的任何支持?可能可以像url一样实现它?
标签: perl dependencies dependency-management build-tools