我目前在一个项目中，该项目使用另一个部门开发的框架作为基础进行开发。我们目前正在我们部门引入质量标准(终于，耶!)，但目前不可能将这些标准引入其他部门。因此，我们正在努力应对一个不断变化的目标，既没有 API 稳定性，也没有稳定版本，这至少是有压力的。
由于我们首先尝试在最终解决问题，因此我们希望尽可能保护自己免受“上游”又名框架代码的更改。我们设想了硬模块依赖:
这是目前为止的计划。现在的问题:
use Module我们只能定义应该使用的最低版本代码。 最佳答案
这是一个非常明智的计划，我通过一个类似 CPAN 的私有(private)存储库来实现它，我一直称之为“DPAN”。您可以从真实的 CPAN(或 BackPAN)中选择您想要的发行版和版本，并从中创建您自己的存储库。您的 CPAN 客户端仅指向此存储库，有效地将版本卡住为您想要的版本。您只在需要时升级。
此外，DPAN 不仅允许您轻松添加自己的本地私有(private)代码，还允许您修改第三方软件包以解决其安装问题等。我在 2009 年夏季刊 The Perl Review 中为这个想法提供了完整的理由。 .您还可以从我的 Creating Your Own CPAN 中查看我的幻灯片在 YAPC::Russia 发表演讲。
如果您对这种解决方案感兴趣，请查看我的 MyCPAN::App::DPAN模块。它需要一个发行版目录并为您完成其余的工作。您将 CPAN 客户端指向它(并确保它不会连接到互联网)，就是这样。
一旦您可以创建自己的存储库，您就可以轻松地创建一个测试存储库。将您认为要升级的版本转储到其中，在测试服务器上部署代码并收集结果。如果您不喜欢结果，可以轻松更改存储库。
我的 DPAN 工作的下一个重要步骤是安装现有的 Perl，包括您可能已安装的任何模块，并创建可为您提供该安装状态的存储库。我拥有完成这项工作所需的所有主要部分，但我有点忙于让几个客户开始使用。
如果您想了解更多有关这些内容的信息，请告诉我。 :)
关于perl - 如何管理 Perl 模块依赖项？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1213217/