Użyj widelca pakietu w zależności od kompilatora

Question

Pracuję nad pakietem laravel (pozwala to nazwać go pakietem A) i wymaga on innego pakietu (pakiet B https://github.com/dropbox/dropbox-sdk-php).

Zrobiłem widelec pakietu B (https://github.com/EmilioBravo/dropbox-sdk-php), wprowadziła pewne zmiany w nowej gałęzi „fix64” i dodał mój GitHub repo jako repozytorium w composer.json pakietu A, jak wskazano w docs kompozytor:

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

Jeśli zgłoszę aktualizacji kompozytor od wewnątrz pakietu a pobiera widelec poprawnie, ale jeśli im przy pakiet a jako zależność w innym projekcie (projekt C) i aktualizacji wezwanie kompozytora z niego, kompozytor twierdzi, że może znajdź dev-fix64.

Problem 1

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

• Emilio-bravo/platforma dev-dropboxfix wymaga Dropbox/Dropbox-sdk dev-fix64 -> bez pakietu pasującego znaleziony.

• Żądanie instalacji emilio-bravo/platformy dev-dropboxfix -> możliwe do zrealizowania przez emilio-bravo/platformę [dev-dropboxfix].

Tylko jeśli dodam moje repo jako repozytoriów w projekcie C composer.json stwierdzi oddział mojego widelca.

W drugą stronę znalazłem klonowanie mojego widelca do repozytorium satis.

Ale to nie jest w porządku. Jak mogę przekonać kompozytora do znalezienia mojego widelca z GitHub?

Answer 1

Dodawanie niestandardowego repozytorium do głównego projektu to jedyny sposób, aby poinformować Composer o nowym źródle.

Celowo robi się to w ten sposób, ponieważ w przeciwnym wypadku repozytorium mogłoby dodawać repozytorium, które mogłoby dodać repozytorium ... bez gwarancji posiadania skończonej listy repozytoriów.

Ponadto, dodanie repo nie stanowi żadnego oświadczenia o tym, które oprogramowanie zostanie znalezione, Kompozytor skanuje każdy znacznik i gałąź. Teoretycznie repozytorium może mieć inną gałąź dla zupełnie innego, dobrze znanego pakietu, oferując nowszą wersję i dodać złośliwe zachowanie.

Generalnie kompozytor wydaje się być dość dobrze dopasowany do ochrony przed zdalnym wykonaniem kodu, z wyjątkiem niedoinformowanej osoby podejmującej złe decyzje.

Jeśli znajdziesz błąd w pakiecie opublikowanym na stronie packagist.org, najlepszym sposobem dla wszystkich jest zaproponowanie żądania ściągnięcia. Drugim najlepszym sposobem byłoby rozwidlenie projektu pod nową nazwą i opublikowanie go również na stronie packagist.org. Poprawienie problemu za pomocą rozwidlonego repo o tej samej nazwie projektu i wskazanie mu Kompozytora jest najgorszym rozwiązaniem i ogólnie możliwe tylko w przypadku zależności od twoich projektów.