hacer - ¿Cómo resolver los conflictos de requisitos de dos paquetes al ejecutar la instalación de Composer?

resolver conflictos git eclipse

Question

Quiero instalar estos dos paquetes:

• "anahkiasen / former": "dev-master"
• "vespakoen / menu": "dev-master"

Pero el compositor dice que cada uno de ellos depende de diferentes versiones de este paquete:

• "anahkiasen / html-object": "dev-master"
• "anahkiasen / html-object": "1.1.2"

Problema 1

- Installation request for anahkiasen/former dev-master -> satisfiable by anahkiasen/former[dev-master].
- Can only install one of: anahkiasen/html-object[dev-master, 1.1.2].
- vespakoen/menu dev-master requires anahkiasen/html-object 1.1.2 -> satisfiable by anahkiasen/html-object[1.1.2].
- anahkiasen/former dev-master requires anahkiasen/html-object dev-master -> satisfiable by anahkiasen/html-object[dev-master].
- Installation request for vespakoen/menu dev-master -> satisfiable by vespakoen/menu[dev-master].

¿Cómo puedo resolverlo?

Answer 1

El problema básico aquí es el uso de sucursales (dev-master) en lugar de versiones etiquetadas. Usar ramas es muy probable que termine en problemas. Estoy viendo las preguntas de Composer en , y cada vez que alguien informa problemas con paquetes, están utilizando ramas de desarrollo y "estabilidad mínima: dev" el 99% del tiempo.

¿Qué esta pasando? Debo suponer que desea instalar estos paquetes por primera vez. Así que Composer no instala, pero actualiza los paquetes. De lo contrario, un conjunto de versiones de trabajo que sean capaces de cumplir con todos los requisitos de la versión se habrían registrado en el composer.lock .

Así que aquí está la situación de dependencia: dos paquetes dependen de un tercer paquete, pero estos dos requieren versiones incompatibles.

¿Puedes arreglarlo? Solo hay una herramienta en el archivo composer.json local que podrá permitir la instalación del tercer paquete: instalarlo con un alias de versión en línea .

"require": {
    "anahkiasen/former": "dev-master",
    "vespakoen/menu": "dev-master",
    "anahkiasen/html-object": "dev-master as 1.1.2" /* add this line */
}

Al instalar la rama dev-master y declararla como la versión 1.1.2, Composer puede resolver las dependencias de ambos paquetes.

El problema con esto es que fallará en el mismo momento en que tenga tres paquetes dependiendo de un cuarto, en tres versiones diferentes.

Lo correcto sería que cada rama de desarrollo incluyera una declaración de alias de rama en THEIR composer.json , lo que permitirá a Composer detectar que la rama dev-master en realidad es equivalente a la versión 1.1.x, que podría haber ayudado aquí (pero no si algún paquete requiere explícitamente un número de versión dado - 1.1.x no es 1.1.2). Agregar alias de rama todavía es algo bueno y debe hacerse. Si un mantenedor desea evitar el mantenimiento constante de este alias de versión codificada en composer.json , también puede desarrollar esa versión en una rama que tenga esa versión .x en su nombre (es decir, "v1.1.x" o "1.1. x "sería detectado por Composer para contener dicha versión en estabilidad de desarrollo).

Tenga en cuenta que el problema que describí en el último párrafo es que los paquetes requieren explícitamente un número de versión dado. Con este enfoque, si necesita un paquete de este tipo, no puede usar una versión diferente de ese paquete dependiente ni en un paquete diferente. Si bien puede haber casos en que se requiera una sola versión, la mejor solución es requerir rangos de versión.

Mi preferencia personal es usar el operador caret para versiones superiores a 1.0: ^1.1.7 requeriría 1.1.7 como versión mínima, pero no se actualizaría a ninguna versión 2.0.0, lo que se considera que tiene cambios incompatibles. Si un paquete se etiqueta cuidadosamente con una nueva versión de acuerdo con las versiones semánticas, esto funciona como un encanto. Nunca te sorprenderían los cambios incompatibles (a menos que, por supuesto, la naturaleza humana interfiera, pero deberías poder detectar este fallo y deshacer la actualización si tu software se rompe).

Para versiones inferiores a 1.0, tenga en cuenta que el operador de caret funciona de manera diferente al operador de tilde: consulte el manual para obtener más detalles . Prefiero tilde para los paquetes bajo mi control que fueron etiquetados 0.x para obtener actualizaciones de características "compatibles" incluso si las versiones semánticas permiten actualizaciones incompatibles en el rango 0.x.

Pero incluso sin la versión semántica, cada pequeña cantidad de inexactitud en el número de versión ayuda, como la definición de 1.1.* (Que supuestamente se actualizará a todas las próximas versiones de corrección de errores) o >=1.1.2,<1.2.5 .

Lo peor de todo es que requiere "dev-master". Si bien esto es muy inexacto (se resolverá ante cualquier posible confirmación en la rama, dependiendo del tiempo que actualice), el problema es que no puede volver a una versión anterior de "dev-master" a menos que sepa exactamente qué confirmación ID que necesita y agregue este requisito a composer.json . Pero entonces estás exactamente en la misma situación anterior que requiere una versión exacta (una etiqueta git es solo un alias con nombre para un ID de confirmación).