Instalar extensões PHP através do PECL

PECL

Algumas vezes necessitamos instalar pacotes para que nosso PHP se comporte de uma forma esperada. Para certas situações podemos usar o PECL.

O que é o PECL

É um repositório de extensões PHP

Ambiente

Os testes foram feitos no ambiente:

• Fedora 31 - 5.4.8-200.fc31.x86_64
• PHP 7.3.13 (cli) (built: Dec 17 2019 10:29:15) ( NTS )

Instalação

O PECL necessita do PEAR instalado, assim, devemos prosseguir com,

dnf install php-pear php-devel

Extensões

Vocẽ pode encontrar diversas extensões no próprio site do PECL https://pecl.php.net/packages.php

Outra opção é utilizar o terminal para a pesquisa de extensões. Suponhamos que necessitamos instalar a extensão "memcache". No seu terminal digite:

pecl search memcache

para a pesquisa realizada teremos o retorno,

Instalação

Depois de encontrar a extensão, devemos fazer a instalação, para isso, utilizaremos o comando:

pecl install memcache

o próximo passo será habilitar a extensão em nosso PHP, o pecl já nos informa o parâmetro a ser adicionado no php.ini

Build process completed successfully

Installing '/usr/lib64/php/modules/memcache.so'
install ok: channel://pecl.php.net/memcache-4.0.5.2

configuration option "php_ini" is not set to php.ini location
You should add "extension=memcache.so" to php.ini

Configuração

Podemos inserir o parãmetro "extension=memcache.so" diretamente no php.ini, ou criar um novo arquivo, exemplo memcache.ini, na pasta de pacotes do php, no meu caso em /etc/php.d/

Agora é somente reiniciar o serviço

systemctl restart php-fpm.service

e utilizar o recurso instalado.

Comments

[Hacker Gaucho]

ainda tem gente usando PECL em 2020? pensava que o packagist já tinha acabado com ele 😮

uma dúvida: se o memcache pode ser instalado através do gerenciador de pacotes do sistema operacional (ubuntu, centos, etc) por que seria interessante instalá-lo através do PECL?

[Mayron Ceccon]

Pelo que conheço, o Packagist tem extensões para código PHP, já o PECL instala extensões no PHP. Usei o memcache como exemplo, não teve motivo especial.

[Hacker Gaucho]

sim, tô ligado que o PECL que faz parte do geranciador de pacotes PEAR compila e gera bytecodes a partir do C enquanto o Packagist só trabalha com scripts PHP, só acho estranho recomendar a utilização do PECL pois recentemente tive um contato imediato com um abandonware do PEAR e acabei encontrando mais de uma alternativa atualizada no Packagist.

sei que até mesmo o php.net as vezes recomendava pacotes do PEAR, porém hoje em dia acho um pouco arriscado recomendar a utilização do PEAR por vários motivos, dentre eles:

1. A crescente popularidade do Packagist e dos pacotes em PHP puro
2. A falta de um padrão rígido de segurança no PEAR
3. A falta de uma linguagem padrão no PECL (Perl, Python, C, etc)
4. A incorporação de bibliotecas o PECL no core das novas versões do PHP

[Mayron Ceccon]

Não estou incentivando. É questão de somente utilizar se for necessário.

[Daniel Rodrigues]

Ainda vale a pena usar pacotes PECL.

[Hacker Gaucho]

Ainda vale a pena usar pacotes PECL.

então explique por gentileza por que vale.

[Daniel Rodrigues]

Pacotes PECL como muitos sabem, são extensões PHP escritas em C, todas elas antes de entrarem na PECL passam por um processo de discussão em uma lista de e-mail pública. Esse processo é bem rigoroso e sujeito a não aprovação. Todas as extensões devem ter testes e deverão ser documentadas no manual PHP. Sou membro do core por isso sei desses processos. Posso estar errado, mas, pacotes PECL ainda são uma parte importante do meio ambiente PHP.

[Hacker Gaucho]

Pacotes PECL como muitos sabem, são extensões PHP escritas em C, todas elas antes de entrarem na PECL passam por um processo de discussão em uma lista de e-mail pública. Esse processo é bem rigoroso e sujeito a não aprovação.

legal, não sabia desse processo rigoroso. removi o item 2 do comentário acima por isso.

Todas as extensões devem ter testes e deverão ser documentadas no manual PHP.

falei sobre isso no item 4, para mim essa é uma das razões para o usuários comuns do PHP que não participam do desenvolvimento de extensões em C aguardarem que elas sejam incorporadas no core do PHP ao invés de usarem elas antes disso.

Posso estar errado, mas, pacotes PECL ainda são uma parte importante do meio ambiente PHP.

essa parte e a mais difícil para eu entender. se o processo de aprovação do PEAR é tão rigoroso mesmo para pacotes em PHP a tendência é surgirem gargalos no desenvolvimento, certo?

até entendo a necessidade de existir um repositório exclusivo para as extensões em C como o PECL, mas o próprio fato da linguagem padrão das extensões ser o C tende a afastar desse repositório os usuários que geralmente programam apenas em PHP.

posso citar como exemplo dessa tendência os 8.6 M de downloads do pacote Net_SMTP contra os 143 M de downloads do pacote swiftmailer/swiftmailer.

outra grande diferença é o número de pacotes. existem apenas 603 pacotes no PEAR enquanto existem mais de 1.8 M de pacotes no Packagist.

por essas e outras razões ainda fico admirado que tem quem ainda use o PEAR para instalar pacotes em PHP ao invés de userem o Packagist.

em suma, vejo um crescente movimento de migração de pacotes PHP do PEAR e do SourceForge para o Packagist mas não estou vendo o contrário.