首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >如何在Perl中管理包级别以上的依赖关系,而不关注CPAN?

如何在Perl中管理包级别以上的依赖关系,而不关注CPAN?
EN

Stack Overflow用户
提问于 2019-02-02 10:17:07
回答 1查看 232关注 0票数 0

这与关于前题CPAN::Meta::Spec有关,它似乎不是为我认为可以使用的东西而设计的。

我的用例

我有不同的Perl应用程序,它们本身包含了很多包,这取决于一些国产的全系统实用程序,当然还有第三方包。这些应用程序可能提供不同的特性,这取决于运行时配置,取决于这些特性,依赖项是不同的。此外,如果自动化测试可用,那么这些测试也可能引入依赖关系,在最近的示例中,默认情况下,在Windows 5.22中,那些依赖项已经在ActiveState上可用,而在Ubuntu16.04中,那些需要使用APT安装的依赖项。

我自己的应用程序和实用工具都是使用Subversion和repos维护的,至少部分用户也可以公开使用。第三方包最好由操作系统的包管理器(如APT )或Perl发行版来维护,比如。只有当某些依赖关系以这种方式不可用时,CPAN才会发挥作用。

我想要达到的..。

...is描述了我的应用程序和系统范围的实用工具,它们的依赖关系使我能够区分运行时和开发或测试,并能够区分可选特性和它们的依赖关系。此外,我想保持一些repos,例如,我自己的应用程序和系统范围的实用程序可以从那里下载。

我不想要的..。

...is可以在多个地方维护我正在使用的每个单独的包,因为这对我来说没有多大意义。APT并不一定安装单独的Perl包,而是包含多个包的更高级别的发行版,例如,一个完整的应用程序。如果引入了依赖项,开发人员无论如何都需要检查这些依赖是否在所有感兴趣的平台上可用(这并不一定是这样的),以及这些依赖在每个平台上的分布方式,例如APT、PPM或CPAN。因此,如果不检查这些包是如何在哪个平台上分布的,那么就不可能容易地引入对单个包的依赖关系。因此,对我的需求来说,管理包级别以上的依赖似乎就足够了,而这正是平台上通常需要维护的部分。

此外,这就是Maven和Gradle的工作方式:我们不依赖于org.apache.commons.lang3.AnnotationUtilsorg.apache.commons.io.ByteOrderMark这样的单独类,而是依赖于包含特定版本中的Apache和Apache的发行版。虽然单个类最终是在某个类中导入的,但项目描述及其依赖关系本身并不包含该级别的详细信息。如果Perl对Java很好地工作,我不明白为什么要深入研究Perl,如果我需要检查发行版级别,那么Perl-依赖关系是否完全可以实现。

我所需要的

因此,我需要的是一些规范/DSL来描述我的项目,包括名称、版本号、依赖项以及最有可能不同的repos。这样的回购将是我自己的SVN-回购或概念,如APT或PPM,在最好的情况下,即使有更多的回复,如果一个人决定主办这样。最后,应该使用Ansible这样的工具来安装我的一些应用程序,同时能够根据每个应用程序/项目中的规范自动处理依赖项,使用插件或附加工具或任何其他工具。

到目前为止我所发现的

对于Perl来说,这就引出了cpanmcpanfileCPAN::Meta::Spec,它们都能够区分运行时和测试,支持可选特性等等,后者甚至可以建模不同的repos。但两者似乎都只支持包上的依赖,而不支持更高的分发级别。不过,我们可以使用一些包作为发行版的占位符来解决这个问题。例如,通过创建包含sysutils.pmpackage sysutils;并只定义某些版本。然后,应用程序可以使用上述格式依赖于该软件包。

到目前为止认识到的缺点

但是人们建议不要手动编写CPAN::Meta::Spec,而是使用一些构建和创作工具。问题在于,有些/大多数被链接的博客文章本身或其他来源认为是不可取的,有些示例甚至只为这些工具提供手动编写的CPAN::Meta::Spec。如果不是,他们有时只是简单地期望CPAN::Meta::Spec的信息以某种自定义的配置格式进行,这似乎不如规范本身定义的那么好。那么,为什么要使用这些工具而不是手工编写规范呢?

即使是CPAN::Meta::Spec本身似乎也是有问题的,因为最近的版本2似乎出于一些未加说明的原因而更喜欢JSON。当然,这是手工编写和维护规范的一个错误决定,因为JSON缺乏注释,在我看来,这对于人类所维护的任何类型的描述都是不可接受的。

问题

  1. 那么,我可以使用哪种格式/规范来使用某个名称和版本手动描述某些抽象发行版,包括它的可选特性和依赖项呢?CPAN::Meta::Spec似乎已经有了很大的可能性,但对于我来说,目前的包级依赖关系似乎太低了。
  2. 应该使用哪个工具来根据以前的规范来解决依赖关系,并支持针对APT、PPM和SVN等依赖项的不同源-repos?
  3. 随着诸如Ansible之类的东西开始发挥作用,是否值得再保留一些Perl特定的描述,还是应该简单地使用Ansible来描述依赖关系,让Ansible提供所有使用插件或其他东西的人?

谢谢你的建议!

EN

回答 1

Stack Overflow用户

发布于 2019-02-02 18:08:07

我想对CPAN::Meta::Spec调用的发行版上的依赖关系进行建模

当使用ExtUtils::MakeMaker时,META_MERGE允许您访问来自元规格的字段,这些字段允许您指定要指定的信息。来自DateTime的以下代码片段::Format::Atom演示了这一点:

代码语言:javascript
复制
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,
         },
      },
   },
},

有关完整的规范,请参阅prereqs

但两者似乎都只支持包上的依赖,而不支持更高的分发级别。“

你对任何事都大惊小怪。您必须使用Foo::Bar而不是Foo并不重要。

票数 1
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/54492053

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档