【问题标题】:How to manage dependencies in Perl ABOVE package level and WITHOUT focussing on CPAN?如何管理 Perl ABOVE ABOVE ABOVE ABOVE 包级别的依赖项而不关注 CPAN?
【发布时间】:2019-06-26 18:31:18
【问题描述】:

这与关于CPAN::Meta::Specformer 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.AnnotationUtilsorg.apache.commons.io.ByteOrderMark,而是依赖于包含这些类的发行版,如某些特定版本中的 Apache Commons Lang 和 Apache Commons IO。虽然最终在某个类中导入了各个类,但项目描述及其依赖项本身并不包含该级别的详细信息。我不明白为什么我应该深入研究 Perl,如果它非常适用于 Java,如果我需要在分发级别检查是否可以完全满足 Perl 依赖项。

我需要什么

所以,我需要一些规范/DSL 来描述我的项目,其中包含一些名称、版本号、它的依赖项以及很可能从哪里获取内容的不同存储库。这样的存储库将是我自己的 SVN 存储库或 APT 或 PPM 之类的概念,如果有人决定托管此类存储库,最好甚至为这些存储库提供额外的存储库。最后,应该使用像 Ansible 这样的工具来安装我的一些应用程序,同时能够根据每个应用程序/项目的规范使用插件或其他工具或其他工具自动处理依赖关系。

到目前为止我发现了什么

对于 Perl,这让我想到了 cpanmcpanfileCPAN::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,在我看来,这对于人类维护的任何类型的描述都是不可行的。

问题

  1. 那么,我可以使用哪种格式/规范来手动描述一些使用某些名称和版本的抽象分发,包括它的可选功能和依赖项? CPAN::Meta::Spec 似乎已经完成了几乎所有的事情,只是目前对我来说,包级别的依赖关系似乎太低了。

  2. 应该使用哪个工具来解决基于之前规范的依赖关系,并支持 APT、PPM 和 SVN 等依赖关系的不同 source-repos?

  3. 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 disturl 实际上看起来很有趣。您是否知道目前对 APTPPM 等包管理器的任何支持?可能可以像url 一样实现它?

标签: perl dependencies dependency-management build-tools


【解决方案1】:

我想对 CPAN::Meta::Spec 调用分布的依赖关系建模

使用 ExtUtils::MakeMaker 时,META_MERGE 允许您访问来自 META spec 的字段,这些字段允许您指定要指定的信息。以下来自 DateTime::Format::Atom 的 sn-p 演示了这一点:

META_MERGE  => {
   'meta-spec' => { version => 2 },

   prereqs => {
      configure => {
         requires => {
            'ExtUtils::MakeMaker'       => 6.74,
         },
      },
      runtime => {
         requires => {
            'strict'                    => 0,
            'version'                   => 0,
            'warnings'                  => 0,
            'DateTime'                  => 0,
            'DateTime::Format::RFC3339' => 0,
         },
      },
      test => {
         requires => {
            'Test::More'                => 0,
         },
      },
      develop => {
         requires => {
            'FindBin'                   => 0,
            'Pod::Coverage'             => 0.18,
            'Test::Pod::Coverage'       => 1.08,
         },
      },
   },
},

请咨询 this 以获取完整的 prereqs 规范。


但两者似乎都只支持对包的依赖,而不是一些更高的分发级别。"

你什么都没有。不必使用 Foo::Bar 而不是 Foo-Bar。

【讨论】:

  • 我没有从你的例子中看到它究竟如何让我依赖我已经知道某些 SVN-Repos 中的名称或分布的 APT RPM 包?您仍然依赖于例如PAUSE 将单个 Perl 包映射到 CPAN 已知的某个发行版,但我不知道为 APT 包做这样的映射。此外,与手动编写 META.* 相比,使用 MakeMaker 更容易的是什么?它是否处理安装依赖项并充当 CPAN 客户端?没有感觉,我不需要makefile,APT和PPM应该处理这些事情。
  • Re "我看不出你的例子是如何让我依赖 APT RPM-packages",它没有。您说您想要“对 CPAN::Meta::Spec 所谓的分布的依赖关系进行建模”。 apt 发行版不是 CPAN 发行版。
  • Re "与手动编写META.* 相比,使用MakeMaker 有什么好处?",你知道cpan 不安装模块吗?它实际上只是一个依赖遍历器和下载器。它调用发行版的Makefile.PLBuild.PL 来进行实际的测试和安装。 MakeMaker 是一个模块安装程序。创建META.* 只是它对您的一点帮助。如果你想手动做,玩得开心。
  • APT-distros 和 CPAN-distros 在概念上与由 CPAN::Meta::Spec 作为依赖项管理的 Perl 包相比在概念上是相同的,后者比发行版低一级。而且因为 CPAN 知道发行版,APT 知道发行版,甚至 SVN 也可能知道基于发行版,例如在其 URL 上,但 APT 和 SVN 都不知道 Perl 包,我想在发行版级别上建模依赖关系。
  • Re "APT-distros 和 CPAN-distros 在概念上是同一个东西",不,一点也不。它们不是相同的格式,也不是在同一个地方找到的。 CPAN 和 APT 是两个完全独立的系统,拥有自己的工具和发行版。
猜你喜欢
  • 2019-03-12
  • 2010-12-04
  • 1970-01-01
  • 1970-01-01
  • 2022-11-11
  • 1970-01-01
  • 2016-12-23
  • 1970-01-01
  • 2022-12-02
相关资源
最近更新 更多