2014-12-31 7 views
5

Ich entwickle ein Laravel-Paket (wir nennen es Paket A) und es erfordert ein anderes Paket (Paket B https://github.com/dropbox/dropbox-sdk-php).Verwenden Sie eine Paket-Verzweigung in einer Composer-Abhängigkeit

Ich habe eine Gabel von Paket B hergestellt (https://github.com/EmilioBravo/dropbox-sdk-php) einige Änderungen in einem neuen Zweig "fix64" und fügte hinzu, meine GitHub Repo als Repository in composer.json von Paket A, wie in den Komponisten docs angegeben:

"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" 
}, 

Wenn ich Komponisten Update aus dem Paket A nenne es meine Gabel herunterlädt richtig, aber, wenn im Paket A als Abhängigkeit in einem anderen Projekt (Projekt C) und Call Komponist Update es nicht verwenden können, sagt Komponist kann Finde nicht dev-fix64.

Problem 1

- emilio-bravo/platform dev-dropboxfix requires dropbox/dropbox-sdk dev-fix64 -> no matching package found. 
  • emilio-Bravo/dev-Plattform erfordert dropboxfix dropbox/dropbox-sdk dev-fix64 -> keine Übereinstimmungen gefunden Paket.

  • Installationsanfrage für emilio-bravo/plattform dev-dropboxfix -> erfüllbar von emilio-bravo/plattform [dev-dropboxfix].

Nur wenn ich meine Repo als Repositories in das Projekt C composer.json hinzufügen es findet Zweig meiner Gabel.

Andersherum habe ich gefunden, kloning meine Gabel in ein satis-Repository.

Aber es fühlt sich nicht richtig an. Wie kann ich den Komponisten dazu bringen, meine Gabel von GitHub zu finden?

+1

Haben Sie jemals eine gültige Lösung gefunden? Ich habe genau das gleiche Problem. –

+1

Mögliches Duplikat von [Wie man eine Verzweigung mit Composer benötigt] (http://stackoverflow.com/questions/13498519/how-to-require-a-fork-with-composer) –

Antwort

2

Das Hinzufügen des benutzerdefinierten Repositorys zum Hauptprojekt ist die einzige Möglichkeit, Composer für die neue Quelle zu sensibilisieren.

Und es ist absichtlich auf diese Weise getan, weil sonst Repos Repos hinzufügen könnten Repos hinzufügen ... ohne eine Garantie, eine endliche Liste von Repos zu haben.

Auch das Hinzufügen eines Repos gibt keine Aussage darüber, welche Software dort zu finden ist. Composer wird jeden Tag und jede Verzweigung scannen. Theoretisch kann ein Repository einen anderen Zweig für ein völlig anderes, wohlbekanntes Paket haben, das eine neuere Version davon bietet, und etwas bösartiges Verhalten hinzufügen.

Composer im Allgemeinen scheint ziemlich gut in Bezug auf Schutz gegen Remotecodeausführung geeignet, mit Ausnahme eines uninformierten Menschen, der schlechte Entscheidungen trifft.

Wenn Sie also einen Fehler in einem Paket finden, das auf packagist.org veröffentlicht wurde, ist der beste Weg für alle, eine Pull-Anfrage zu stellen. Der zweitbeste Weg wäre, das Projekt unter einem neuen Namen herauszufiltern und es auch auf packagist.org zu veröffentlichen. Das Patchen des Problems mit einem gegabelten Repo mit demselben Projektnamen und Hinweisen auf Composer ist die schlechteste Lösung und im Allgemeinen nur für Abhängigkeiten von eigenen Projekten möglich.

Verwandte Themen