Respostas:
Atualização : O problema foi corrigido no Composer 1.3 . Atualize o composer para a versão mais recente executando composer self-update
, em vez de tentar a seguinte solução alternativa.
Aqui está minha modificação do código de @ ezzatron. Eu atualizei o script para detectar arquivos ini da saída do phpinfo.
#!/bin/sh
php_no_xdebug () {
temporaryPath="$(mktemp -t php.XXXX).ini"
# Using awk to ensure that files ending without newlines do not lead to configuration error
php -i | grep "\.ini" | grep -o -e '\(/[a-z0-9._-]\+\)\+\.ini' | grep -v xdebug | xargs awk 'FNR==1{print ""}1' | grep -v xdebug > "$temporaryPath"
php -n -c "$temporaryPath" "$@"
rm -f "$temporaryPath"
}
php_no_xdebug /usr/local/bin/composer.phar $@
# On MacOS with composer installed using brew, comment previous line
# Install jq by executing `brew install jq` and uncomment following line.
# php_no_xdebug /usr/local/Cellar/composer/`brew info --json=v1 composer | jq -r '.[0].installed[0].version'`/libexec/composer.phar $@
bin/bash
vez de /bin/sh
, pois este último não gostou da function
palavra - chave (Ubuntu 14.04 LTS).
composer self-update
Este comando desabilitará o módulo PHP5 Xdebug para CLI (e, portanto, composer):
sudo php5dismod -s cli xdebug
Ele remove o link simbólico xdebug.ini de/etc/php5/cli/conf.d/
Isso foi sugerido em http://blog.lorenzbausch.de/2015/02/10/php-disable-xdebug-for-cli/
Observe que para o Ubuntu 16.04 você provavelmente precisará executá-lo desta forma:
sudo phpdismod -s cli xdebug
alias xdebug-on='sudo php5enmod -s cli xdebug'
e alias xdebug-off='sudo php5dismod -s cli xdebug'
, então agora é fácil habilitar xdebug-on
e desabilitar o xdebug-off
xdebug.
Não acho que haja uma opção para configurar o PHP para que ele possa carregar configurações diferentes de acordo com o script de destino. Pelo menos, não sem duplicar arquivos .ini ...
No entanto, você pode adicionar essas opções ao executar o composer com php:
php -n -d extension=needed_ext.so composer.phar
-n
irá dizer ao PHP para ignorar qualquer php.ini. Isso evitará que o xdebug carregue para este comando.
-d
options permite que você adicione qualquer opção que desejar (por exemplo, ative needed_ext.so). Você pode usar várias -d
opções. Claro, isso é opcional, você pode não precisar dele.
Depois, você pode criar um alias para torná-lo adocicado novamente.
Uma solução típica (porque o compositor precisa do json):
php -n -d extension=json.so composer.phar
greg0ire> minha solução, com base nisso:
#!/bin/bash
options=$(ls -1 /usr/lib64/php/modules| \
grep --invert-match xdebug| \
# remove problematic extensions
egrep --invert-match 'mysql|wddx|pgsql'| \
sed --expression 's/\(.*\)/ --define extension=\1/'| \
# join everything together back in one big line
tr --delete '\n'
)
# build the final command line
php --no-php-ini $options ~/bin/composer $*
alias composer=/path/to/bash/script.sh
Parece feio (tentei e não consegui fazer isso com xargs), mas funciona ... Tive que desabilitar algumas extensões, caso contrário, recebo os seguintes avisos:
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/mysqli.so' - /usr/lib64/php/modules/mysqli.so: undefined symbol: mysqlnd_connect in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/pdo_mysql.so' - /usr/lib64/php/modules/pdo_mysql.so: undefined symbol: pdo_parse_params in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/pdo_pgsql.so' - /usr/lib64/php/modules/pdo_pgsql.so: undefined symbol: pdo_parse_params in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/wddx.so' - /usr/lib64/php/modules/wddx.so: undefined symbol: php_XML_SetUserData in Unknown on line 0
-n
ontem e tive um problema porque estava faltando a phar
extensão. Vou tentar adicionar mais e mais extensões até funcionar, acho que é uma boa solução. De acordo com o alias, já tenho alguns aliases zsh que não mantenho. Talvez eu tente substituir o binário por um script bash ou ver se consigo configurar os aliases.
composer.json
, por exemplo "ext-ldap": "*", ou simplesmente dependendo do que é necessário para fazer as tarefas pós-instalação funcionarem corretamente … Se ao menos houvesse uma maneira de colocar uma extensão na lista negra…
php -m
diagnose
e, como estou construindo contêineres docker de desenvolvimento para minha equipe, a menor melhoria na velocidade poderia beneficiar todos eles
Ao criar um alias, você suprimirá essa composer
xdebug
mensagem de erro.
Basta adicionar essa linha ao ~/.bash_aliases
seu sistema e ela deve funcionar perfeitamente.
alias composer="php -n /usr/local/bin/composer"
Recarregue o shell para disponibilizar o novo alias composer
.
source ~/.bash_profile
USO:
$ composer --version
NOTA:
Você não precisa necessariamente usar nenhum outro parâmetro.
Dependendo do seu sistema, você pode ter um em .bashrc
vez de .bash_profile
.
ATUALIZAR:
Como @AlexanderKachkaev mencionou nos comentários, não vale a pena adicionar o memory_limit da seguinte forma para evitar travar em algumas situações:
alias composer="php -d memory_limit=-1 -n /usr/local/bin/composer"
-n
opção desativa a Phar
extensão para que ele possa falhar ao executar a partir decomposer.phar
alias composer="php -d memory_limit=-1 -n /usr/local/bin/composer"
Eu encontrei uma resposta que funciona muito bem para OSX e provavelmente poderia ser adaptada para qualquer versão do PHP que carregue suas extensões usando arquivos .ini individuais no "diretório ini adicional":
#!/bin/sh
function php-no-xdebug {
local temporaryPath="$(mktemp -t php-no-debug)"
find /opt/local/etc/$1/php.ini /opt/local/var/db/$1/*.ini ! -name xdebug.ini | xargs cat > "$temporaryPath"
php -n -c "$temporaryPath" "${@:2}"
rm -f "$temporaryPath"
}
alias composer="php-no-xdebug php56 ~/bin/composer"
Normalmente crio um script de shell por projeto, já que cada projeto tem outra versão do PHP. Ele está em um /bin/
diretório próximo a composer.phar
e composer.json
e eu o executo como ./bin/composer
no diretório do meu projeto.
É assim (para php56)
#!/bin/sh
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
COMPOSER_DISABLE_XDEBUG_WARN=1 /opt/local/bin/php56 \
-d xdebug.remote_enable=0 -d xdebug.profiler_enable=0 \
-d xdebug.default_enable=0 $DIR/../composer.phar "$@"
As -d
opções desabilitam efetivamente o xdebug. A COMPOSER_DISABLE_XDEBUG_WARN=1
parte desativa os problemas do compositor de aviso.
É preferível desativar a extensão xdebug (consulte a solução de problemas do compositor ), mas eu pessoalmente gosto do script mais simples.
Alguns intervalos na minha máquina: 2 Executar com xdebug e ini habilitado: 1m33
Executar com xdebug mas ini-disabled: 0m19
Executar sem xdebug: 0m10
COMPOSER_DISABLE_XDEBUG_WARN=1
: se você receber um aviso, isso significa apenas que seu scrit não funciona. Definir xdebug.remote_autostart
parece inútil se a depuração remota estiver desativada.
xdebug.remote_autostart
. Sobre a eficácia dos scripts: o Composer verifica se a extensão xdebug está carregada, e não se está realmente fazendo algo, olhe o código aqui . As opções ini funcionam bem em scripts php "normais", mas novamente: eu não fiz testes de desempenho ...
Se você usar o PHPStorm, a versão mais recente (2016.2) vem com um recurso para habilitar o XDebug para scripts CLI sob demanda, o que significa que você pode simplesmente desligar o XDebug globalmente em sua máquina de desenvolvimento. O IDE o habilitará rapidamente quando for necessário para o código dentro de seus projetos.
PhpStorm 2016.2 introduz o modo Xdebug On Demand onde você pode desabilitar o Xdebug para sua instalação PHP global, e PhpStorm só o habilitará quando for necessário - quando você estiver depurando seus scripts, ou quando precisar de relatórios de cobertura de código.
Você precisa editar suas preferências de intérpretes PHP para incluir o caminho para o XDebug, conforme descrito no artigo vinculado.
Para mim, esta parece ser a solução perfeita, já que normalmente só quero o XDebug enquanto estou no IDE.
No entanto, o XDebug tem outros usos potenciais quando você está "offline", por exemplo, despejos de pilha estendidos em logs de erro, que você perderia desligando-o globalmente. É claro que você não deve ter o XDebug habilitado na produção, portanto, isso seria limitado a casos de uso como testes beta ou scripts CLI de teste automatizado em desenvolvimento.
Em vez de se confundir com a ativação ou desativação temporária do módulo PHP, quando você pode ter processos simultâneos usando PHP (por exemplo, como parte de um pipeline de CI), você pode dizer ao PHP para apontar para um diretório de carregamento de módulo diferente.
Embora seja semelhante a algumas das soluções mencionadas acima, isso resolve alguns casos extremos, o que é muito útil quando usado pelo Jenkins ou outro executor de CI que executa testes na mesma máquina simultaneamente.
A maneira mais fácil de fazer isso é usar a variável de ambiente PHP_INI_SCAN_DIR
Usar isso em um script ou tarefa de construção é fácil:
export PHP_INI_SCAN_DIR=/etc/php.d.noxdebug
php composer install
Claro que você gostaria de preparar /etc/php.d.noxdebug primeiro, fazendo algo como:
mkdir /etc/php.d.noxdebug
cp /etc/php.d/* /etc/php.d.noxdebug
rm /etc/php.d.noxdebug/xdebug.ini
Isso significa que você tem um ambiente semelhante ao antigo ambiente php, com apenas um módulo faltando. Significa que você não precisa se preocupar em carregar os módulos phar / json como faria com a solução php -n.
Eu vim com uma solução para o instalador do Composer baseado no Windows - ele deve funcionar para qualquer instalação do Composer, ele basicamente faz uma cópia do arquivo INI carregado e comenta a extensão zend do xdebug, então carrega o arquivo de configuração quando executa o composer .
Abri um problema para ver se eles gostariam de integrar essa mudança:
https://github.com/composer/windows-setup/issues/58
Você pode encontrar minhas instruções e código lá.
Conforme observado na resposta de Joyce , esse problema não existe mais na versão mais recente do Composer.
A documentação do Composer foi atualizada para observar isso . Ele detalha como você pode habilitar o xdebug com o Composer (se necessário).
Você pode atualizar sua versão do Composer utilizando a atualização automática .
No meu Mac, tive que fazer: sudo php /opt/local/bin/composer self-update
Mais detalhes sobre isso no contexto de uma instalação do Homebrew PHP podem ser encontrados nesta edição .
Aqui está minha contribuição com base em uma instalação do PHP instalado no Homebrew no Mac OS X.
É um wrapper de script de shell, projetado para ser salvo como um arquivo executável em /usr/local/bin/composer
, com o binário do Composer em /usr/local/bin/composer.phar
:
#!/bin/sh
sed -i '' -e 's:zend_extension="/usr/local/opt/php55-xdebug/xdebug.so":;zend_extension="/usr/local/opt/php55-xdebug/xdebug.so":' /usr/local/etc/php/5.5/conf.d/ext-xdebug.ini
/usr/local/bin/php /usr/local/bin/composer.phar "$@"
sed -i '' -e 's:;zend_extension="/usr/local/opt/php55-xdebug/xdebug.so":zend_extension="/usr/local/opt/php55-xdebug/xdebug.so":' /usr/local/etc/php/5.5/conf.d/ext-xdebug.ini
O script de wrapper:
O script é acoplado a uma instalação OS X / Homebrew do PHP 5.5. Os caminhos devem ser ajustados para funcionar com outras versões do PHP e layouts de diretório de outros sistemas operacionais e gerenciadores de pacotes. Observe também que algumas versões do sed não precisam do argumento de string vazia após o-i
opção.
O script é simples, pois funciona diretamente nos principais arquivos de configuração do PHP, no entanto isso também é uma desvantagem: o Xdebug também será desabilitado para quaisquer scripts que sejam executados simultaneamente com este script.
Em meu ambiente de desenvolvimento, essa é uma compensação aceitável, visto que o Composer é executado manualmente e apenas ocasionalmente; entretanto, você pode não querer usar esta técnica se estiver executando o Composer como parte de um processo de implantação automatizado.
Na maioria dos casos, você não precisa do xdebug no modo CLI. Se isso for aceitável para você, você pode configurar cli e cgi de forma diferente.
Portanto, se você criar php-cli.ini e conf-cli.d perto de sair do arquivo php.ini, poderá configurar cli e cgi de forma diferente (para cgi seriam php.ini e conf.d ). Apenas não coloque xdebug.ini em conf-cli.d.
Se você instalar o composer usando o brew no OS X, você pode usar este alias:
alias composer="php -n $(cat $(which composer) | grep composer.phar | awk '{print $7}')"
Minha solução rápida para uma instalação macports, com várias versões do PHP, foi escrever este invólucro de shell simples para o Composer:
/user/local/bin/composer-nodebug.sh
#!/bin/bash
sudo mv /opt/local/var/db/php53/xdebug.ini /opt/local/var/db/php53/xdebug.NOT
sudo mv /opt/local/var/db/php54/xdebug.ini /opt/local/var/db/php54/xdebug.NOT
sudo mv /opt/local/var/db/php55/xdebug.ini /opt/local/var/db/php55/xdebug.NOT
composer $1 $2 $3 $4 $5 $6 $7
sudo mv /opt/local/var/db/php53/xdebug.NOT /opt/local/var/db/php53/xdebug.ini
sudo mv /opt/local/var/db/php54/xdebug.NOT /opt/local/var/db/php54/xdebug.ini
sudo mv /opt/local/var/db/php55/xdebug.NOT /opt/local/var/db/php55/xdebug.ini
Em seguida, execute quaisquer comandos do compositor como:
sudo composer-nodebug.sh update
Desvantagens:
Não é elegante, mas simples.
$1…$7
... talvez seja $@
ou algo parecido, você terá que procurar.
Criação de um alias para o composer para desativar o xdebug e evitar erros de memória:
Adicione esta linha ao seu ~ / .bash_profile
alias composer='php -d xdebug.profiler_enable=0 -d memory_limit=-1 /usr/local/bin/composer'
Reinicie o terminal para disponibilizar o novo alias.
Aqui está minha solução rápida para me livrar do aviso do Xdebug na versão PHP5-cli. Removi o suporte do Xdebug para PHP5-cli no Ubuntu 14.04.
cd /etc/php5/cli/conf.d/
sudo rm 20-xdebug.ini
Agora não há mais aviso Xdebug no PHP5-cli.
sudo phpdismod xdebug
seria o método preferido para bruterm