Questo è lo scenario.Risolvi l'inferenza dipendente con il compositore
Avete il pacchetto A e il pacchetto B nel vostro compositore.json (la vostra app dipende da questi 2 pacchetti).
Entrambi i pacchetti A e B dipendono dal pacchetto C, ma su versioni diverse. Dire A dipende da C v2.1, e B dipende da C v2.2.
E si ottengono conflitti di versione.
Entrambi A, B e C sono pacchetti di terze parti.
Come risolvere questo?
Questo è un hack ma probabilmente ti permetterà di andare avanti.
È possibile sovrascrivere i repository per i pacchetti "A", "B" e "C" e fare in modo che "A" e "B" facciano affidamento sulla stessa versione di "C" (in realtà, potrebbe essere sufficiente sovrascrivere repository solo per "A" e "B").
Questo dovrebbe funzionare fintanto che sia "A" che "B" possono funzionare con l'ultima versione di "C" (quindi probabilmente un manutentore non ha aggiornato la versione del pacchetto). Se è il caso, prenderemmo in considerazione l'invio di una richiesta pull al progetto che ha una versione più vecchia di una dipendenza.
Perché il compositore non consente al pacchetto A e al pacchetto B di dipendere da versioni diverse dello stesso pacchetto. NPM è in grado di farlo: http://blog.timoxley.com/post/20772365842/node-js-npm-reducing-dependency-overheads Hanno solo bisogno di una sorta di struttura del fornitore annidata! – CMCDragonkai
Sei anche in grado di dare un esempio all'interno di composer.json su come sovrascrivere i repository per risolvere il conflitto di dipendenze? – CMCDragonkai
Stiamo discutendo in questa mailing list: http://news.php.net/php.internals/72594
"No-conflitto" tecnica deve essere implementato in PHP, non è un compositore colpa
Direi che questo è un problema concettuale della separazione della gestione delle dipendenze e della mancanza di contesto durante l'autoload delle librerie. Anche se php fornirebbe un modo semplice, per includere la stessa libreria con versioni diverse nella stessa richiesta (ad esempio il loader del compositore esporterebbe la versione in spazi dei nomi separati), dovresti comunque mappare in qualche modo le chiamate dalle tue librerie a la versione di dipendenza corretta. – Tyrael
@Tyrael Sembra un problema minore; è possibile creare alias lo spazio dei nomi radice del pacchetto in modo che FQNS includa la versione del pacchetto ma venga fatto riferimento nel modo normale. per esempio. /Vendor/Package/1.0.0/ è alias come/Vendor/Package /; anche se penso che sarebbe necessario limitare le modifiche alla versione installate in modo indipendente, con le versioni secondarie semplicemente sovrascrivendo quelle esistenti. – Marvin
È possibile per A o B per lavorare con il stessa versione di C? So che diverse versioni sono forzate da quei pacchetti ma probabilmente potresti definire repository per quei tre nel tuo compositore.json per sovrascrivere le versioni. So che è un trucco ma potrebbe farti andare. –
Sì, lo è. Ma non sono sicuro che tu possa farlo. Ci proverò. ma so se inserisci il tuo compositore.json '" C ":" 2.2 "', e A have '" C ":" 2.1 "', otterrai degli errori. – umpirsky
Sì, ma la mia idea è di definire i repository per tutti e tre i pacchetti. Quindi modifichi A e B per fare affidamento su "C": "2.2". Finché entrambi possono funzionare con 2.2 ... –