在我看来,PEAR再次崛起,至少作为一种分配机制.由于实际上简单的简单PEAR通道服务器(例如 Pirum)的可用性,似乎许多项目正朝着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渠道带来更多的软件包,我如何管理所有网站的所有依赖项？我不可能是唯一一个患此的人.比我聪明的人必须已经解决了这个问题.

编辑：到目前为止我找到了Pearanha.基本上它为您的特定项目生成一个自定义PEAR.这需要在构建步骤中集成,因为它不会使PEAR存储库可移动.

pear-switch承诺使PEAR存储库可移动,但它不起作用.它是硬编码来处理注册表文件和pearcmd.PHP中的硬编码包含路径,但它不处理在安装过程中替换为PHP文件的任何其他路径.