Uso di un fork di pacchetto in una dipendenza di compositore

Question

Sto sviluppando un pacchetto laravel (chiamiamolo pacchetto A) e richiede un altro pacchetto (pacchetto B https://github.com/dropbox/dropbox-sdk-php).

Ho fatto un fork del pacchetto B (https://github.com/EmilioBravo/dropbox-sdk-php), ha apportato alcune modifiche in un nuovo ramo "fix64" e ha aggiunto il mio repo GitHub come un repository in composer.json del pacchetto A, come indicato nella documentazione compositore:

"repositories": [ 
    { 
     "type": "vcs", 
     "url": "https://github.com/EmilioBravo/dropbox-sdk-php" 
    } 
], 
"require": { 
    "php": ">=5.4.0", 
    "illuminate/support": "4.2.*", 
    "dropbox/dropbox-sdk": "dev-fix64" 
}, 

Se chiamo aggiornamento compositore all'interno del pacchetto a che scarica la forchetta in modo corretto, ma, se im utilizzando il pacchetto a come una dipendenza in un altro progetto (project C) e l'aggiornamento chiamata compositore da esso, compositore dice che può trovo dev-fix64.

Problema 1

- emilio-bravo/platform dev-dropboxfix requires dropbox/dropbox-sdk dev-fix64 -> no matching package found. 

• emilio-bravo/platform dev-dropboxfix richiede dropbox/set-sdk-dev fix64 -> nessun pacchetto corrispondente trovato.

• Richiesta di installazione per emilio-bravo/piattaforma dev-dropboxfix -> soddisfacente da emilio-bravo/piattaforma [dev-dropboxfix].

Solo se aggiungo il mio repo come repository della C composer.json progetto si trova ramo di mia forchetta.

L'altro modo che ho trovato è clonare la mia forchetta in un repository satis.

Ma non sembra giusto. Come posso convincere il compositore a trovare la mia forchetta da GitHub?

Answer 1

L'aggiunta del repository personalizzato al progetto principale è l'unico modo per rendere Composer consapevole della nuova origine.

Ed è intenzionalmente fatto in questo modo, perché altrimenti repos potrebbe aggiungere repos potrebbe aggiungere repos ... senza una garanzia di avere un elenco finito di repository.

Inoltre, l'aggiunta di un repository non fornisce alcuna indicazione su quale software si trovi lì, Compositore eseguirà la scansione di ogni tag e ramo. In teoria un repository può avere un altro ramo per un pacchetto completamente diverso, ben noto, che offre una versione più recente di esso e aggiunge alcuni comportamenti malevoli.

Compositore in generale sembra essere molto adatto per quanto riguarda la protezione contro l'esecuzione di codice in modalità remota, ad eccezione di una cattiva decisione di prendere decisioni sbagliate.

Quindi, se trovi un bug in un pacchetto pubblicato su packagist.org, il modo migliore per tutti è proporre una richiesta di pull. Il secondo modo migliore sarebbe quello di biforcare il progetto con un nuovo nome e pubblicarlo anche su packagist.org. Rattoppare il problema usando un repository biforcato con lo stesso nome del progetto e indicando Compositore è la soluzione peggiore e generalmente fattibile solo per le dipendenze dei propri progetti.