问题描述
这与，它似乎并不是针对我认为可以使用的内容而设计的。
This is related to a former question about CPAN::Meta::Spec, which doesn't seem to be designed for what I thought I could use it.
我有不同的Perl应用程序，其中包含许多程序包，具体取决于一些本地开发的系统范围实用程序的东西，当然还有第三者套餐。这些应用程序可能会提供不同的功能，具体取决于运行时配置，并且取决于这些功能，依存关系也有所不同。此外，如果可以使用自动测试，则这些测试也可能会引入依赖关系，在最新示例中，默认情况下，Windows上的ActiveState Perl 5.22中已经存在这些依赖关系，而在Ubuntu 16.04上，则需要使用APT安装这些依赖关系。
I have different Perl apps containing of a lot of packages themself, depending on some home grown system wide utility stuff and of course 3rd party packages. Those apps might provide different features depending on runtime config and depending on those features, dependencies are different. Additionally, if automated tests are available, those might introduce dependencies as well and in the most current example those dependencies where available in ActiveState Perl 5.22 on Windows by default already, where on Ubuntu 16.04 those needed to be installed using APT.
我自己的应用程序和实用程序是使用Subversion进行维护的，并且该回购协议至少也可以部分公开提供给客户。第三方软件包最好由OS的软件包管理器维护，例如APT或Perl发行版，例如Windows上ActiveState Perl的PPM。仅当某些依赖方式无法使用时，CPAN才会发挥作用。
My own apps and utility stuff are maintained using Subversion and the repos at least partly publicly available to customers as well. 3rd party packages are preferred to be maintained by the package manager of the OS like APT or the Perl distribution, like PPM for ActiveState Perl on Windows. Only if some dependency is not available that way, CPAN comes into play.
...正在描述我的应用程序和系统范围内的实用程序及其相关性，从而使我能够区分例如运行时来自开发或测试，并且能够区分可选功能及其依赖项。此外，我想在以下位置维护一些存储库我自己的应用程序和系统范围的实用程序可以从这里下载。
...is describing my apps and system wide utility stuff with their dependencies in a way that allows me to distinguish e.g. runtime from development or tests and being able to distinguish optional features and their dependencies. Additionally, I would like to maintain some repos where e.g. my own apps and system wide utilities can be downloaded from.
...是要在多个地方维护我在某个地方使用的每个软件包，因为这对我来说意义不大。 APT不一定安装单个Perl软件包，而是安装一些更高版本的发行版，其中包含多个Perl软件包，例如完整的应用程序。如果引入了依赖关系，则开发人员无论如何都需要检查这些依赖关系是否在所有感兴趣的平台上都可用（不一定是这种情况）以及如何在每个平台上进行分配，例如APT，PPM或CPAN。因此，如果不检查那些程序包如何分布在哪个平台上，就很难轻易引入对各个程序包的依赖性。因此，对于我来说，需要在一个程序包级别之上管理依赖关系似乎已经足够了，无论如何，多数情况下，这都是在平台上进行维护的。
...is to maintain at multiple places each and every individual package I'm using somewhere, because that doesn't make much sense to me. APT is not necessarily installing individual Perl packages, but instead some higher level distribution containing multiple of those, a complete app for example. If dependencies are introduced, developers need to check anyway if those are available on all platforms of interest, which is not necessarily the case, and how those are distributed on each platform, e.g. APT, PPM or CPAN. So dependencies on individual packages can not be introduced easily without checking how those packages are distributed on which platform. Therefore it seems enough for my needs to manage dependencies ABOVE a package level, which is what mostly gets maintained on platforms anyway.
此外，这就是例如Maven和Gradle的工作原理：不依赖于像 org.apache.commons.lang3.AnnotationUtils 或 org.apache.commons.io这样的单个类.ByteOrderMark ，但是在包含某些特定版本的类（如Apache Commons Lang和Apache Commons IO）的发行版中。最后，将单个类导入某个类中，但项目描述及其依存关系本身不包含该级别的详细信息。我不知道为什么我应该深入研究Perl，如果它对Java很好，并且无论如何我都需要检查发行版本，是否可以完全满足Perl的依赖性。
Additionally, this is how e.g. Maven and Gradle work: One doesn't depend on individual classes like org.apache.commons.lang3.AnnotationUtils or org.apache.commons.io.ByteOrderMark, but on distributions containing those classes like Apache Commons Lang and Apache Commons IO in some specific version. While individual classes are imported in some class in the end, the project description and its dependencies itself doesn't contain that level of detail. I don't see why I should dive deeper in Perl if it works for Java pretty well and if I need to check at distribution level anyway if Perl-dependencies can be fulfilled at all.
所以，我需要的是一些spec / DSL来描述我的项目，包括一些名称，版本号，其依赖项以及最可能的不同存储库从哪里得到东西。这样的仓库可以是我自己的SVN仓库，也可以是APT或PPM之类的概念，如果决定托管此类仓库，充其量也不过是额外的仓库。最后，应该使用Ansible之类的工具来安装我的某个应用程序，同时能够根据每个应用程序/项目的规范使用插件或其他工具或其他工具自动处理依赖项。
So, what I need is some spec/DSL to describe my project with some name, version number, its dependencies and most likely different repos where to get things from. Such a repo would be my own SVN-repos or concepts like APT or PPM, at best even with additional repos for those, if one decides to host such. In the end, some tools like Ansible should be used to install some app of mine while being able to deal with dependencies automatically, using plugins or additional tools or whatever, based on the specs in each app/project.
对于Perl，这导致我进入，和都可以区分运行时与测试，支持可选功能等。后者甚至可以对不同的仓库进行建模。但是两者似乎都只支持对软件包的依赖，而不是更高的发行级别。不过，也许可以使用某些软件包充当发行版的占位符来解决此问题。例如。通过创建包含软件包sysutils; 的 sysutils.pm 并仅定义某些版本。然后，应用可以使用上述格式依赖于该软件包。
For Perl this lead me to cpanm, cpanfile and CPAN::Meta::Spec, both being able to distinguish runtime from test, support optional features etc. The latter can even model different repos. But both only seem to support dependencies on package instead of some higher distribution level. One might be able to work around this using some packages acting as placeholder for distributions, though. E.g. by creating sysutils.pm containing package sysutils; and defining some version only. Apps could then depend on that package using the above formats.
建议不要手动编写 CPAN :: Meta :: Spec ，而是使用一些。这些问题是链接博客文章本身或认为已淘汰了部分/大部分>甚至有些示例甚至仅向这些工具提供手动编写的 CPAN :: Meta :: Spec 。如果不是这样，他们有时只是希望以某种自定义配置格式获取 CPAN :: Meta :: Spec 的信息，这似乎没有规范本身定义的好。那么，为什么不使用这些工具而不是手动编写规范呢？
But people e.g. recommend to not write CPAN::Meta::Spec manually, but use some build and authoring tools instead. The problem with those is that some/most are considered deprecated by the linked blog post itself or other sources and some examples even are providing manually written CPAN::Meta::Spec to those tools in the end only. And if not, they sometimes simply expect infos of CPAN::Meta::Spec in some custom configuration format, which seems not as well defined as the spec itself. So why use those tools at all instead of writing the spec manually?
即使 CPAN :: Meta :: Spec 本身似乎是有问题的，因为最新的版本2似乎出于某些未记录的原因而倾向于 JSON 。当然，这对于手动编写和维护该规范是一个错误的决定，因为 JSON 缺少注释，我认为这对人类维护的任何形式的描述都是不可行的。
Even the CPAN::Meta::Spec itself seems to be problematic, as the most current version 2 seems to prefer JSON for some undocumented reason. That is a bad decision for manually writing and maintaining that spec of course, because JSON lacks comments, which is a no-go for any kind of description maintained by humans in my opinion.
-
所以，我可以使用哪种格式/规格用于使用一些名称和版本手动描述一些抽象分发，包括其可选功能和依赖项？
So, which format/spec can I use to manually describe some abstract distribution using some name and version, including it's optional features and dependencies? Pretty much what seems to be possible with
CPAN::Meta::Specalready, only that package level dependencies seem too low level for me currently.
应该使用哪个工具基于以前的规范来解决依赖关系，并为APT，PPM和SVN等依赖关系支持不同的源存储库？
Which tool should be used to resolve dependencies based on the former spec and supports different source-repos for dependencies like APT, PPM and SVN?
随着诸如Ansible之类的事情开始起作用，是否值得再保留一些Perl特定的描述，还是应该仅仅使用Ansible来描述依赖关系，然后让Ansible提供所有使用插件或其他工具的人，这是否值得？
With things like Ansible coming into play, is it worth it to maintain some Perl-specific description at all anymore or should one simply use Ansible to describe dependencies and let Ansible provide all of those using plugins or whatever?
感谢您的建议！
推荐答案
在使用ExtUtils :: MakeMaker时， META_MERGE 可让您访问，可让您指定要指定的信息。 DateTime :: Format :: Atom的以下代码段演示了这一点：
When using ExtUtils::MakeMaker, META_MERGE gives you access to fields from the META spec that allow you to specify the information you want to specify. The following snippet from DateTime::Format::Atom demonstrates this:
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-Bar。
You're making a fuss about nothing. It doesn't matter that you have to use Foo::Bar instead of Foo-Bar.
这篇关于如何在Perl之上的包级别中管理依赖性，而又不关注CPAN？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！