subido - Diferente archivo php.ini cargado dependiendo del contenido del código

php.ini cpanel

Question

Estoy realmente perdido respecto a lo que está pasando: todo comenzó con un error de error de la unidad PHP Error: No code coverage driver is available al intentar ejecutar el informe de cobertura de prueba y terminó con la depuración a un conjunto replicable que se describe a continuación. Pero para preparar el escenario, estoy usando Laravel 5.5, Xdebug 2.5.5, PHPUnit 6.5.5. Mi código de prueba que ilustra el problema:

<?php

use Tests/TestCase;

class A extends TestCase
{
    public function testA()
    {
        echo( get_cfg_var(''cfg_file_path'')); exit;
    }
}

produce C:/Users/xxx/AppData/Local/Temp/7598.tmp

compárelo con este código que genera la ruta php.ini correcta:

<?php

use PHPUnit/Framework/TestCase;

class A extends TestCase
{
    public function testA()
    {
        echo( get_cfg_var(''cfg_file_path'')); exit;
    }
}

salidas: C:/server/php/php.ini

¿Cómo puede ser? ¿Cómo puede el archivo php.ini cargado cambiar dependiendo del código ejecutado? Mejor aún, ¿cómo se puede cargar mi archivo php.ini correcto (que tiene xdebug habilitado) en lugar de este impostor?

En ambos casos, las pruebas se phpunit tests/unit/a utilizando phpunit tests/unit/a

La estructura de la carpeta es:

Laravel Project
└───tests
    └───Unit
        └───A.php

Answer 1

Lo hemos rastreado hasta un problema con la función XdebugHandler.php::writeTmpIni ubicada en el vendor/composer/composer/src/Composer/XdebugHandler.php .

Aparentemente, durante la inicialización de la aplicación, se genera un proceso de php separado con php.ini temporal, y al proceso de php se le pasa la prueba, pero el motivo por el que se hace es por lo que actualmente está fuera de mi alcance.

Lo marcará en el bugtracker de Laravel sobre qué hacer con esto.

La dependencia que agrega Composer, como un paquete (en mi caso) es larapack/hooks , que en sí misma es una dependencia para larapack/voyager-hooks , que en sí misma es una dependencia para Voyager.

Por lo que sé, durante la inicialización de la aplicación Laravel, este comportamiento no debería activarse (por qué inicializar una dependencia que no es necesaria, al menos explícitamente). ¿Por qué el compositor se dispara en esa etapa también me supera?

La solución que hemos aplicado es agregar:

<php>
    <env name="COMPOSER_ALLOW_XDEBUG" value="1"/>
</php>

en el archivo phpunit.xml

Ahora he enviado esto como un problema: https://github.com/laravel/framework/issues/22782

Por discusión en GitHub, esto se debe al cambio en Laravel 5.5, en lo que respecta al manejo de proveedores de servicios ( https://laravel.com/docs/5.5/packages#package-discovery ). Cómo se actualiza, no lo sé; para mí, es un cambio entre 5.4 y 5.5 que merece una nota en las actualizaciones (pero, por favor, lea la discusión que ocurrió en Github y tome su propia decisión sobre el asunto). Para ser honesto, reportar este problema dejó un mal sabor de boca y no lo seguiré buscando.

También he abierto un problema en larapack/voyager-hooks en relación con el descubrimiento de proveedores de servicios presentado en 5.5 - https://github.com/larapack/voyager-hooks/issues/16

Esto ahora se ha corregido en larapack/hooks:v1.0.3

Answer 2

Tuve algunos otros problemas que me parecieron raros antes. Parece que estás usando la máquina de Windows como tu dev. No estoy seguro de su instalación de php. Pero lo que me sucedió fue que tuve muchas instancias diferentes de apache, php, phpunit, nginx, mysql ubicadas en diferentes carpetas.

Mi punto es que parece que tienes muchos PHP instalados en tu máquina. Y por alguna razón, se están utilizando diferentes intérpretes de php para 2 casos descritos en OP.

Puedo estar equivocado y aún no tengo respuesta en mi comentario sobre los comandos y las carpetas que usa para ejecutar ambas pruebas.

Pero solo puedes salir

echo PHP_BINDIR;

en ambas pruebas para asegurarse de que el mismo intérprete php esté en uso en ambos casos.