☰

如何管理 PEAR 包的依赖关系

tag-icon • tag-icon php dependencies pear
如何管理 PEAR 包的依赖关系

在我看来，PEAR 至少作为一种分发机制正在再次流行起来。随着简单的 PEAR 渠道服务器的出现，实际上简单（例如皮鲁姆) 似乎许多项目都转向使用 PEAR 作为分发机制。一些示例包括 PHPUnit、Phing、Symfony2、Doctrine2 等。然而，我在尝试管理这一点时遇到了严重的麻烦。

我不想再使用单个系统范围的 PEAR。我在一台服务器上有几十个网站，所有网站都使用通过 PEAR 渠道分发的各种库。其中一些网站很旧。有些有冲突的依赖关系。我不想每次出现新的软件包版本时都要检查 30 多个网站。但同时，当我在开发新网站时，我也不想被困在某个古老的软件包版本上。

我已经为此绞尽脑汁好一阵子了。PEAR 作为一种分发机制似乎完全不适合在同一台服务器上运行多个站点的任何设置。似乎不可能在一台机器上维护多个并行的 PEAR 存储库，或将 PEAR 存储库签入版本控制。

很多问题似乎是由于 PEAR 在安装时替换 PHP 文件中的某些路径，而不是在运行时解析它们而引起的。例如，Phing 想知道 PEAR 在哪里data_dir。安装文件时phing/Phing.php，字符串@data_dir@将被data_dir当时的 替换。但这使得无法移动它或将其置于版本控制之下。

我知道 Pyrus 和 PEAR2 应该能解决很多问题，但目前看来它们并不是可行的选择。我的许多网站都依赖于未移植到 PEAR2 的 PEAR 软件包。而且 Pyrus 对 PEAR 通道实现非常挑剔，导致许多 PEAR1 通道无法与 Pyrex 一起使用（例如，由于 eZcomponents.org 上的配置错误，PHPUnit 拒绝与 Pyrus 一起安装）。

那么，随着未来似乎将通过 PEAR 渠道提供越来越多的软件包，我该如何管理我所有网站的所有依赖项？我不可能是唯一一个受此困扰的人。一定有比我更聪明的人已经解决了这个问题。

编辑：到目前为止我发现皮拉尼亚。基本上，它会为您的特定项目生成自定义 PEAR。但这需要在构建步骤中集成，因为它不会使 PEAR 存储库可移动。

梨开关承诺使 PEAR 存储库可移动，但无法实现。它采用硬编码来处理注册表文件和硬编码的包含路径pearcmd.php，但不处理在安装期间替换到 PHP 文件中的任何其他路径。

答案1

使用下一代 Pear 安装程序 Pyrus，并按照使用 Pyrus 管理 PEAR 可安装供应商库。

答案2

Christian 是对的。Pyrus 是管理应用程序的 PEAR 可安装供应商依赖项的本地注册表的最佳方式。

我认为您遇到的问题是由实施不当的包/渠道引起的，而不是 pyrus 或方法特有的问题。

例如，Pyrus 不允许用户自定义 data_dir 的路径，因此安装可以是自包含的，并且包可以依赖于 data_dir 文件所在的位置。

例如，使用新注册表目录布局的供应商目录如下所示：

data   <--- role = data
docs   <--- role = doc
php    <--- role = php
tests  <--- role = test
www    <--- role = www

不要使用 @data_dir@ 替换，而是使用基于当前目录的路径，例如

dirname(__DIR__).'/data/pear.channel.com/PackageName/datafile';

分发 PEAR 可安装库的开发人员应该修改他们的软件包以使用较新的注册表目录布局标准，而不是依赖将安装绑定到特定机器的路径替换。

相关内容