Question

我目前正在使用由另一个部门开发的框架作为基础开发的项目。我们目前正在我们的部门引入质量标准（最后，yay！），但目前无法将这些标准引入其他部门。因此，我们正在努力克服一个不断变化的目标，没有API稳定性或稳定版本，这至少会带来压力。

由于我们首先尝试解决问题，因此我们希望确保自己能够抵御“上游”a.k.a.框架代码的变化。我们设想了硬模块依赖：

仅使用代码中定义的某些版本范围的框架模块。
使用单元测试检查以确保所有必需的版本仍然可用。
每个版本范围扩展都需要对框架代码进行同行评审。

到目前为止，这是计划。现在的问题是：

这是明智的吗？如果没有，还有其他想法吗？
如何在perl中实现此功能？使用use Module我们只能定义应该使用的最低版本代码。

Answer 1

这是一个非常明智的计划，我通过类似CPAN的私有存储库来实现它，我一直称之为“DPAN”。您可以从真实的CPAN（或BackPAN）中选择所需的发行版和版本，并从中创建自己的存储库。您的CPAN客户端仅指向此存储库，有效地将版本冻结到您想要的版本。您只能在需要时升级。

此外，DPAN不仅可以轻松添加您自己的本地私有代码，还可以修改第三方软件包以修复其安装问题等。我在2009年夏季刊中完全证明了这一想法。 The Perl Review。您还可以在YAPC :: Russia的Creating Your Own CPAN演讲中看到我的幻灯片。

如果您对此类解决方案感兴趣，请查看我的MyCPAN::App::DPAN模块。它需要一个发行版目录，并为您完成剩下的工作。您将CPAN客户端指向它（并确保它不会连接到互联网）就是这样。

一旦您可以创建自己的存储库，您就可以轻松地创建测试存储库。转储您认为要升级到其中的版本，在测试服务器上部署代码并收集结果。如果您不喜欢结果，可以轻松更改存储库。

我的DPAN工作中的下一个重要步骤是使用您可能安装的任何模块来安装现有的Perl，并创建可以为您提供安装状态的存储库。我拥有完成这项工作所需的所有主要部分，但是我有点忙于让几个客户在第一时间运行。

如果您想更多地了解这些内容，请告诉我们。：）

Answer 2

看看PAR。它允许您将一组依赖项捆绑到一个文件中。您可以使用它们发布的模块，将它们放入PAR文件中，只有在想要接受更改时才升级PAR文件。

Answer 3

虽然我希望CPAN比您所依赖的模块更稳定，但我想问一个类似的问题：您如何保护自己免受CPAN模块中的意外更改？

答案是：您要下载模块并在测试环境中对其进行回归。

可以在这里使用吗？您是否必须指向其模块的“实时”副本，还是指向您自己的副本？

Answer 4

我会通过制作我的代码依赖的库的私有副本并将它们放在我的项目的lib目录中来理解我将永远不会修改这些副本，除非定期检查新版本作为里程碑到达了。

Answer 5

我认为Carton是您正在寻找的东西（perl的捆绑器）。结合plenv，我相信这样做会有所作为。

Answer 6

有人已经指出PAR了。让我提一下PAR::Repository和它的伴随模块PAR::Repository::Client。它们实现了一个客户端/服务器基础结构，可以自动加载本地未找到的任何依赖项（或者甚至更喜欢服务器的软件包）。作为管理员，您只需在存储库中添加或删除包。实际的包服务是使用完全正常的服务器完成的：任何http服务器或简单地文件：//都可以。其他协议应该很容易实现。

它具有上述魔术自动加载机制，软件包安装和自动软件包升级。除了模块文档之外，您还可以查看presentation on PAR from YAPC::Europe 2008，在某种程度上涵盖了这一点。

我不得不承认，自动升级是一项足够先进的技术，如果全部用完小猫啃咬，可能会吃掉一两个婴儿。

Answer 7

如果你想检查外部模块的版本，你可以（至少他们正确报告他们的$ VERSION）使用这样的东西：

BEGIN {
    use foo;
    use bar;

    die "Ghaaaa" if $foo::VERSION < 2.1;
    die "Aaaargh" if $foo::VERSION > 3.12;
}

如何管理Perl模块依赖项？

7 个答案: