Este es el escenario.Resolviendo el infierno de dependencia con el compositor
Tiene el paquete A y el paquete B en su composer.json (su aplicación depende de estos 2 paquetes).
Ambos paquetes A y B dependen del paquete C, pero en diferentes versiones. Say A depende de C v2.1, y B depende de C v2.2.
Y obtienes conflictos de versión.
Ambos A, B y C son paquetes de terceros.
¿Cómo resolver esto?
Esto es un truco, pero probablemente te permita seguir adelante.
Puede sobrescribir repositorios para paquetes "A", "B" y "C" y hacer que "A" y "B" dependan de la misma versión de "C" (de hecho, podría ser suficiente para sobrescribir) repositorios para "A" y "B" solamente).
Esto debería funcionar siempre que tanto "A" como "B" puedan funcionar con la última versión de "C" (por lo que probablemente un mantenedor no actualizó la versión del paquete). Si es el caso, también consideraría enviar una solicitud de extracción al proyecto que tiene una versión anterior de una dependencia.
¿Por qué el compositor no permite que el paquete A y el paquete B dependan de diferentes versiones del mismo paquete? NPM puede hacer esto: http://blog.timoxley.com/post/20772365842/node-js-npm-reducing-dependency-overheads ¡Solo necesitan algún tipo de estructura de proveedor anidada! – CMCDragonkai
¿También puede dar un ejemplo dentro del composer.json sobre cómo sobrescribir los repositorios para resolver el conflicto de dependencia? – CMCDragonkai
Estamos discutiendo en esta lista de correo: http://news.php.net/php.internals/72594
"No-conflicto" técnica debe ser implementado en PHP, no es un compositor de fallos
Me gustaría argumentar que este es un problema conceptual de la separación de la gestión de la dependencia y la falta de contexto al cargar automáticamente sus libs. Incluso si php proporcionaría una manera fácil, para incluir la misma biblioteca con diferentes versiones en la misma solicitud (por ejemplo, el cargador de compositores exportaría la versión a espacios de nombres separados), aún tendría que asignar de alguna manera las llamadas de sus libs a la versión de dependencia adecuada. – Tyrael
@Tyrael Parece un problema menor; puede alias el espacio de nombre raíz del paquete para que el FQNS incluya la versión del paquete pero se haga referencia a él de la manera normal. p.ej. /Vendor/Package/1.0.0/ tiene un alias como/Vendor/Package /; aunque creo que necesitaría limitar los cambios de versión que se instalan de manera independiente, con versiones menores simplemente sobrescribiendo el existente. – Marvin
¿Es posible que ya sea A o B para trabajar con el misma versión de C? Sé que diferentes versiones son forzadas por esos paquetes, pero probablemente puedas definir repositorios para esos tres en tu composer.json para sobrescribir las versiones. Sé que es un truco, pero podría dejarte ir. –
Sí lo es. Pero no estoy seguro de que puedas hacer eso. Lo intentaré. pero sé que si pones en tu compositor.json '" C ":" 2.2 "', y A tienes '" C ":" 2.1 "', obtendrás errores. – umpirsky
Sí, pero mi idea es definir repositorios para los tres paquetes. Entonces cambia A y B para confiar en "C": "2.2". Mientras ambos puedan funcionar con 2.2 ... –