Como gerenciar dependências em pacotes PEAR

Question

Parece-me que a PEAR está recuperando o vapor novamente, pelo menos como um mecanismo de distribuição. Com a disponibilidade de servidores de canal PEAR simples que são realmente simples (por exemplo, Pirum ), parece que muitos projetos estão se movendo em direção ao PEAR como um mecanismo de distribuição. Alguns exemplos incluem PHPUnit, Phing, Symfony2, Doctrine2, etc. No entanto, estou com sérios problemas tentando gerenciar isso.

Eu não quero mais usar um único PEAR em todo o sistema. Eu tenho dezenas de sites em um único servidor, todos usando várias bibliotecas distribuídas pelos canais PEAR. Alguns desses sites são antigos. Alguns têm dependências conflitantes. Eu não quero ter que checar mais de 30 sites toda vez que uma nova versão do pacote aparecer. Mas, ao mesmo tempo, não quero ficar preso a uma versão antiga do pacote quando estou trabalhando em um novo site.

Eu tenho me deixado de cabeça por algum tempo agora. O PEAR como um mecanismo de distribuição parece ser completamente inadequado para qualquer tipo de configuração em que vários sites são executados no mesmo servidor. Parece impossível manter muitos repositórios PEAR paralelos em uma única máquina ou verificar repositórios PEAR no controle de versão.

Muitos problemas parecem ser causados porque o PEAR substitui determinados caminhos em arquivos PHP no momento da instalação, em vez de resolvê-los em tempo de execução. Por exemplo, o Phing quer saber onde está o PEAR data_dir . Quando o arquivo phing/Phing.php é instalado, a string @data_dir@ é substituída por qualquer que seja o data_dir nesse momento. Mas isso torna impossível movê-lo ou mantê-lo sob controle de versão.

Eu sei que o Pyrus e o PEAR2 devem resolver muitos problemas, mas eles parecem não ser opções viáveis neste momento. Muitos dos meus sites dependem de pacotes PEAR não portados para o PEAR2. E o Pyrus está sendo muito exigente em relação às implementações do canal PEAR, tornando muitos canais PEAR1 inutilizáveis com o Pyrex (por exemplo, o PHPUnit se recusa a instalar com o Pyrus devido a um erro de configuração no eZcomponents.org).

Então, com um futuro que parece trazer cada vez mais pacotes através dos canais PEAR, como posso gerenciar todas essas dependências para todos os meus sites? Eu não posso ser o único a sofrer com isso. Alguém mais esperto do que eu já deve ter resolvido esse problema.

EDIT : Até agora eu encontrei Pearanha . Basicamente, ele gera um PEAR personalizado para seu projeto específico. Isso precisaria ser integrado em uma etapa de construção, já que não torna os repositórios PEAR móveis.

O

pear-switch promete tornar um repositório PEAR móvel, mas não funciona. Ele é codificado para lidar com os arquivos de registro e o caminho de inclusão embutido em pearcmd.php , mas não manipula nenhum outro caminho que tenha sido substituído nos arquivos PHP durante a instalação.

    

Answer 1

Use o Pyrus, o instalador de pêra next-gen e siga as instruções em Usando o Pyrus para gerenciar pacotes de fornecedores instaláveis do PEAR .

    

Answer 2

Christian está certo. O Pyrus é a melhor maneira de gerenciar um registro local de dependências de fornecedores instaláveis em PEAR para seu aplicativo.

Acho que os problemas que você está enfrentando são causados por pacotes / canais mal implementados, e não por problemas específicos do pyrus ou do método.

O Pyrus não permite que o usuário personalize o caminho para o data_dir, por exemplo, portanto, a instalação pode ser autocontida e os pacotes podem confiar em onde os arquivos data_dir estão localizados.

Por exemplo, um diretório de fornecedor usando o novo layout de diretório do registro se parece com:

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

Em vez de uma substituição @ data_dir @, use um caminho baseado no diretório atual, como

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

Os desenvolvedores que distribuem bibliotecas instaláveis pelo PEAR devem modificar seus pacotes para usar os mais novos padrões de layout de diretório de registro, em vez de depender de substituições de caminho que vinculam a instalação a uma máquina específica.