php - mac - Deshabilitar xdebug al ejecutar composer

xdebug php 5.6 3 (16)

Manipulación directa de la configuración de PHP

Aquí está mi contribución basada en una instalación de PHP instalada en Homebrew en Mac OS X.

Es un contenedor de script de shell, diseñado para guardarse como un archivo ejecutable en /usr/local/bin/composer , con el binario Composer en /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

teoría de operación

El script de envoltura:

usa sed para modificar temporalmente el archivo de configuración, deshabilitando Xdebug (línea 2)
ejecuta Composer, pasando por argumentos al comando (línea 3)
usa sed para restaurar el archivo de configuración, volviendo a habilitar Xdebug (línea 4)

El script está acoplado a una instalación de OS X / Homebrew de PHP 5.5. Las rutas deben ajustarse para que funcionen con otras versiones de PHP y diseños de directorios de otros sistemas operativos y administradores de paquetes. Tenga en cuenta también que algunas versiones de sed no necesitan el argumento de cadena vacía después de la opción -i .

Utilizador de advertencia

El script es sencillo, ya que funciona directamente en los principales archivos de configuración de PHP, sin embargo , esto también es un inconveniente: Xdebug también estará deshabilitado para cualquier script que se ejecute simultáneamente con este script.

En mi entorno de desarrollo, esta es una compensación aceptable, dado que Composer se ejecuta manualmente y solo ocasionalmente; sin embargo, es posible que no desee utilizar esta técnica si ejecuta Composer como parte de un proceso de implementación automatizado.

Cuando ejecuto el composer diagnose , aparece el siguiente error:

La extensión xdebug está cargada, esto puede ralentizar un poco a Composer. Se recomienda deshabilitarlo cuando se usa Composer.

¿Cómo puedo desactivar xdebug solo cuando estoy ejecutando Composer?

Al crear un alias, suprimirá ese mensaje de error de xdebug composer .

Simplemente agregue esta línea a sus ~/.bash_aliases dentro de su sistema y debería funcionar perfectamente.

alias composer="php -n /usr/local/bin/composer"

Vuelva a cargar el shell para que el nuevo alias composer esté disponible.

source ~/.bash_profile

USO:

$ composer --version

NOTA:
No necesariamente necesita usar ningún otro parámetro.
Dependiendo de su sistema, puede tener un .bashrc lugar de .bash_profile .

ACTUALIZAR:

Como @AlexanderKachkaev menciona en los comentarios, no vale la pena agregar memory_limit de la siguiente manera para evitar fallas en algunas situaciones:

alias composer="php -d memory_limit=-1 -n /usr/local/bin/composer"

Aquí está mi solución rápida para deshacerme de la advertencia de Xdebug en la versión PHP5-cli. He eliminado el soporte de Xdebug para PHP5-cli en Ubuntu 14.04.

cd /etc/php5/cli/conf.d/

sudo rm 20-xdebug.ini

Ahora no más advertencias de Xdebug en PHP5-cli.

Como se señaló en la respuesta de Joyce , este problema ya no existe en la última versión de Composer.

La documentación de Composer ha sido actualizada para tener esto en cuenta Detalla cómo puede habilitar xdebug con Composer (si es necesario).

Puede actualizar su versión de Composer utilizando self-update .

En mi Mac tuve que hacer: sudo php /opt/local/bin/composer self-update

En este número se pueden encontrar más detalles sobre esto en el contexto de una instalación de Homebrew PHP.

Crear un alias para el compositor para deshabilitar xdebug y evitar errores de memoria:

Agregue esta línea a su ~ / .bash_profile

alias composer=''php -d xdebug.profiler_enable=0 -d memory_limit=-1 /usr/local/bin/composer''

Reinicie el terminal para que el nuevo alias esté disponible.

En la mayoría de los casos, no necesita xdebug en modo CLI. Si esto es aceptable para usted, puede configurar cli y cgi de manera diferente.

Entonces, si hace que php-cli.ini y conf-cli.d casi salgan del archivo php.ini, puede configurar cli y cgi de manera diferente (para cgi sería php.ini y conf.d ). Simplemente no ponga xdebug.ini en conf-cli.d.

En lugar de confundirse con habilitar o deshabilitar temporalmente el módulo PHP, cuando pueda tener procesos concurrentes usando PHP (por ejemplo, como parte de una tubería de CI), puede decirle a PHP que apunte a un directorio de carga de módulo diferente.

Si bien esto es similar a algunas de las soluciones mencionadas anteriormente, resuelve algunos casos extremos, lo cual es muy útil cuando Jenkins u otro corredor de CI que ejecuta pruebas en la misma máquina al mismo tiempo.

La forma más fácil de hacer esto es usar la variable de entorno PHP_INI_SCAN_DIR

Usar esto en un script o tarea de compilación es fácil:

export PHP_INI_SCAN_DIR=/etc/php.d.noxdebug php composer install

Por supuesto, primero querrá preparar /etc/php.d.noxdebug, haciendo algo como:

mkdir /etc/php.d.noxdebug cp /etc/php.d/* /etc/php.d.noxdebug rm /etc/php.d.noxdebug/xdebug.ini

Esto significa que tiene un entorno similar al antiguo entorno php, con solo un módulo faltante. Lo que significa que no debe preocuparse por cargar los módulos phar / json como lo haría con la solución php -n.

Este comando deshabilitará el módulo PHP5 Xdebug para CLI (y, por lo tanto, compositor):

sudo php5dismod -s cli xdebug

Elimina el enlace simbólico xdebug.ini de /etc/php5/cli/conf.d/

Esto se sugirió en http://blog.lorenzbausch.de/2015/02/10/php-disable-xdebug-for-cli/

Tenga en cuenta que para Ubuntu 16.04 probablemente necesite ejecutarlo así:

sudo phpdismod -s cli xdebug

Mi solución rápida para una instalación de macports, con múltiples versiones de PHP, fue escribir este simple envoltorio de shell para 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

A continuación, ejecute los comandos del compositor así:

sudo composer-nodebug.sh update

Inconvenientes:

requiere sudo (a menos que modifique los archivos INI)
si lo matas a mitad de camino, los archivos INI se modifican
requerirá futuras versiones de PHP agregadas.
mientras se ejecuta, otros procesos PHP se ven afectados

No elegante, pero simple.

No creo que haya una opción para configurar PHP para que pueda cargar diferentes configuraciones de acuerdo con el script objetivo. Al menos, no sin duplicar archivos .ini ...

Sin embargo, puede agregar estas opciones al ejecutar composer con php:

php -n -d extension=needed_ext.so composer.phar

-n le dirá a PHP que ignore cualquier php.ini. Esto evitará que xdebug se cargue para este mismo comando.

-d options le permite agregar cualquier opción que desee (por ejemplo, active needed_ext.so). Puede usar múltiples opciones -d . Por supuesto, esto es opcional, es posible que no lo necesite.

Luego puedes crear un alias para volverlo azucarado.

Una solución típica (porque el compositor necesita json):

php -n -d extension=json.so composer.phar

greg0ire> mi solución, basada en eso:

#!/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 feo (intenté y no pude hacerlo con xargs), pero funciona ... Sin embargo, tuve que deshabilitar algunas extensiones, de lo contrario recibo las siguientes advertencias:

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

Por lo general, creo un script de shell por proyecto, ya que cada proyecto tiene otra versión de PHP. Está en un directorio /bin/ junto a composer.phar y composer.json y lo ejecuto como ./bin/composer en mi directorio de proyecto.

Se ve así (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 "$@"

Las opciones -d desactivan efectivamente xdebug. La parte COMPOSER_DISABLE_XDEBUG_WARN=1 deshabilita los problemas del compositor de advertencia.

Se prefiere deshabilitar la extensión xdebug (ver resolución de problemas del compositor ), pero personalmente me gusta el script más simple.

Algunos tiempos en mi máquina: 2 Ejecutar con xdebug y habilitado para ini: 1m33

Ejecutar con xdebug pero ini-disabled: 0m19

Ejecutar sin xdebug: 0m10

Se me ocurrió una respuesta que funciona bastante bien para OSX, y probablemente podría ser adaptada para cualquier versión de PHP que cargue sus extensiones usando archivos .ini individuales en el "directorio de entrada 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"

Se me ocurrió una solución para el instalador de Composer basado en Windows: debería funcionar para cualquier instalación de Composer, simplemente hace una copia del archivo INI cargado y comenta la extensión xdebug zend, luego carga ese archivo de configuración cuando ejecuta Composer .

Abrí un problema para ver si les gustaría integrar este cambio:

https://github.com/composer/windows-setup/issues/58

Puede encontrar mis instrucciones y mi código allí.

Si instala composer usando brew en OS X, puede usar este alias:

alias composer="php -n $(cat $(which composer) | grep composer.phar | awk ''{print $7}'')"

Si usa PHPStorm, la última versión (2016.2) viene con una función para habilitar XDebug para scripts de CLI a pedido, lo que significa que simplemente puede apagar XDebug globalmente en su máquina de desarrollo. El IDE lo habilitará sobre la marcha cuando lo necesite el código dentro de sus proyectos.

https://blog.jetbrains.com/phpstorm/2016/06/xdebug-on-demand-for-cli-php-scripts-in-phpstorm-2016-2-eap/

PhpStorm 2016.2 presenta el modo Xdebug On Demand donde puede deshabilitar Xdebug para su instalación global de PHP, y PhpStorm solo lo habilitará cuando sea necesario, cuando esté depurando sus scripts o cuando necesite informes de cobertura de código.

Debe editar sus preferencias de Intérpretes PHP para incluir la ruta a XDebug, como se describe en el artículo vinculado.

Para mí, esta parece ser la solución perfecta, ya que generalmente solo quiero XDebug mientras estoy en el IDE.

Sin embargo, XDebug tiene otros usos potenciales cuando está "fuera de línea", por ejemplo, volcados de pila extendidos en registros de errores, que perdería al desactivarlo globalmente. Por supuesto, no debería tener XDebug habilitado en la producción, por lo que esto se limitaría a casos de uso como scripts de prueba beta o scripts CLI de prueba automatizada en desarrollo.

Actualización : el problema se ha solucionado en Composer 1.3 . Actualice Composer a la última versión ejecutando composer self-update , en lugar de intentar la siguiente solución.

Aquí está mi modificación del código de @ezzatron. He actualizado el script para detectar archivos ini desde la salida de 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 $@