Repozitář na GitHubu commitujete i složku s frameworkem?
- Hadi.k
- Člen | 12
Jaké je dle Vás nejlepší řešení když dáváte celý projekt na GitHub (který je postavený na Nette).
Vidím spoustu repozitářů, které mají složku vendor vč. celého Nette, což mi nepříjde úplně jako dobré řešení a hlavně to ani nevypadá pěkně. Pak Vám tam naskáče 100 000 řádků které napsal David :D.
Je jasné že se dají nastavit závislosti do compeseru, ale to není odpověd na mou otázku :)
Já to většinou řeším tak že tam dám (app, tests a www).
Budu rád za jaké koliv rady a připomínky, díky :)
Editoval Hadi.k (24. 10. 2015 20:25)
- Azathoth
- Člen | 495
CZechBoY napsal(a):
Nejlepší je verzovat composer.lock a knihovny tam vůbec neuploadovat.
snad composer.json, ne? Na co je mi composer.lock?
Samozřejmě jsou výjimky: pokud sdíím kód s někým, kdo nemá k dispozici compoer nebo s ním neumí (např. si jen zdrojáky copypastne na server), tak se to hodí. Ale pokud není důvod, proč tam vendora mít, tak ho doporučuji necommitovat.
- Jiří Nápravník
- Člen | 710
Composer.json i composer.lock – v locku je konkretni verze, co je stazena… jinak ja nahrávám i vendor složku.
Editoval Jiří Nápravník (24. 10. 2015 21:35)
- Šaman
- Člen | 2665
Azathoth napsal(a):
CZechBoY napsal(a):
Nejlepší je verzovat composer.lock a knihovny tam vůbec neuploadovat.
snad composer.json, ne? Na co je mi composer.lock?
Samozřejmě jsou výjimky: pokud sdíím kód s někým, kdo nemá k dispozici compoer nebo s ním neumí (např. si jen zdrojáky copypastne na server), tak se to hodí. Ale pokud není důvod, proč tam vendora mít, tak ho doporučuji necommitovat.
Obojí, ale composer.json je kód, ten se verzuje z principu.
Ale pokud chceš zajistit, aby na ostatnich strojích byla stejná (odladěná)
verze knihoven, tak je dobré vezrovat i composer.lock a na
nevývojářskych strojích instalovat závislosti pomocí
composer install, který natahá ty verze které jsou v
.lock. Nepoužívat composer update, protože to by
nahrálo nejnovější verzi knihoven, která splňuje podmínku.
- Jan Tvrdík
- Nette guru | 2595
@Hadi.k Je to o hodně složitější problém, než se na první pohled zdá. Existuje velké množství dobrých argumentů pro obě strany. Nicméně jsem toho názoru, že pro většinu projektů vychází o něco výhodněji commitovat celou vendor složku, i když ti skoro všichni budou tvrdit opak. Lidí, kteří ti řeknou, že jedna ze stran je jednoznačně lepší jsou obvykle zcela mimo a ten problém vůbec nechápu.
Kdysi jsem to mírně rozepsal na develu, ale i tam je ta problematika vysvětlená hodně zjednodušeně.
- Tomáš Votruba
- Moderator | 1114
@Hadi.k Doporučuju vyzkoušet oba přístupy. Sám tak nejrychleji zjistíš, co ti sedí a jaké to má pro tvůj konkrétní projekt výhody a nevýhody.
Vem si, že pokud commituješ 10 tříd a využíváš 5 balíčků, je to jiný případ než když máš 200 tříd, 50 balíčků.
Stejně tak záleží na počtu osob pracujících na projektu. Pro
1 člověka to příliš nemá smysl. Pokud je vás ale víc a neustále
upravujete composer.json, aby všem konečně fungoval, smysl to
mít bude.
- newPOPE
- Člen | 648
A co tak sa zamyslet aj nad tym ze velke % projektov ktore su v PHP potrebuju aj veci ine ako PHP framework a PHP libs.
S projektom su zavislosti napr. pre npm alebo
bower a tam uz sa zacinaju ine problemy.
Povedzme, ze neverzujes vendor z PHP. A vypadky sluzieb packagist a Ghub vies vyriesit Satis-om. Lenze co s bowerom a npm? Mozno su na to projekty ako Satis lenze tym vznikaju dalsie zavislosti a potom to vsetko uz dosahuje uz velkost maleho „slona“…
Editoval newPOPE (25. 10. 2015 10:19)