Мне кажется, что PEAR снова набирает обороты, по крайней мере, как механизм распространения. Благодаря наличию простых серверов каналов PEAR, которые фактически простой (например, Пирум) Кажется, что многие проекты движутся в сторону PEAR как механизма распространения. Некоторые примеры включают PHPUnit, Phing, Symfony2, Doctrine2 и т. Д. Однако я сталкиваюсь с серьезными проблемами, пытаясь справиться с этим.
Я больше не хочу использовать одну общесистемную PEAR. У меня есть десятки веб-сайтов на одном сервере, и все они используют различные библиотеки, распространяемые через каналы PEAR. Некоторые из этих сайтов старые. У некоторых есть противоречивые зависимости. Я не хочу проверять 30+ сайтов каждый раз, когда появляется новая версия пакета. Но в то же время я не хочу зацикливаться на какой-то древней версии пакета, когда работаю над новым сайтом.
Я уже довольно давно ломаю себе голову над этим. PEAR как механизм распространения кажется совершенно непригодным для любого типа настройки, когда несколько сайтов работают на одном сервере. Кажется невозможным поддерживать множество параллельных репозиториев PEAR на одной машине или проверять репозитории PEAR в системе контроля версий.
Многие проблемы возникают из-за того, что PEAR заменяет определенные пути в файлах PHP во время установки, а не разрешает их во время выполнения. Например, Финг хочет знать, где находится ГРУША data_dir является. Когда файл phing/Phing.php установлен, строка @data_dir@ заменяется тем, что data_dir в то время. Но это делает невозможным его перемещение или сохранение под контролем версий.
Я знаю, что Pyrus и PEAR2 должны решить множество проблем, но на данный момент они не кажутся жизнеспособными. Многие из моих сайтов зависят от пакетов PEAR, не портированных на PEAR2. Pyrus очень привередлив к реализации каналов PEAR, что делает многие каналы PEAR1 непригодными для использования с Pyrex (например, PHPUnit отказывается устанавливать с Pyrus из-за неправильной конфигурации на eZcomponents.org).
Итак, в будущем, которое, похоже, принесет еще больше пакетов через каналы PEAR, как я могу управлять всеми этими зависимостями для всех моих веб-сайтов? Я не могу быть единственным, кто страдает от этого. Кто-то умнее меня, должно быть, уже решил эту проблему.
РЕДАКТИРОВАТЬ: Пока что нашел Pearanha. По сути, он генерирует собственный PEAR для вашего конкретного проекта. Однако это необходимо интегрировать на этапе сборки, поскольку он не делает репозитории PEAR подвижными.
груша обещает сделать репозиторий PEAR подвижным, но это не работает. Он жестко запрограммирован для работы с файлами реестра, и жестко запрограммированный путь включения в pearcmd.php, но он не обрабатывает другие пути, которые были заменены в файлах PHP во время установки.
Кристиан прав. 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, должны изменить свои пакеты, чтобы использовать новые стандарты компоновки каталогов реестра, вместо того, чтобы полагаться на замену пути, которая привязывает установку к конкретному компьютеру.
Используйте Pyrus, установщик груш нового поколения, и следуйте инструкциям в Использование Pyrus для управления устанавливаемыми библиотеками поставщиков PEAR.