Jak testovat -dev verze balíčků s Composerem?
- David Grudl
- Nette Core | 8227
Vyšla nová testovací verze balíčku (případně více balíčků) a
chtěl bych je otestovat. Co dát co composer.json? Píše se
3.1.x-dev nebo 3.1@dev? Jak se to liší? Co dělat,
když je nějaký balíček třetí strany uzamčený na 3.0? Jak to ovlivňují
prefer-stable a další direktivy?
Nevím :-) A plavu v tom.
Prosím, kdo s tím máte zkušenosti, podělte se o své hownou :-) A následně z toho někdo vydestilujte kapitolu do https://doc.nette.org/…ces/composer
Díky moc!
- nightfish
- Člen | 518
Vykopnu lehkým úvodem:
Pravidla v composer.json se skládají ze dvou až tří částí:
- název balíčku (např.
nette/application) a dvojtečky - specifikace verze (např.
3.1.1,^3.1,dev-master) (version constraint) - nepovinné specifikace stability (stability flag) (od specifikace
verze se odděluje zavináčem a může nabývat jedné z hodnot
dev,alpha,beta,RC,stable)
Specifikace verze může obsahovat:
- konkrétní tag (
3.1.1) - větev (píše se s prefixem
dev-– např.dev-bugfixnebo suffixem.x-dev– např.v1.x-dev) - rozsah verzí
- ~ nebo ^
Pokud pro daný balíček neuvedete specifikaci stability, použije se
stable – composer tedy nedovolí instalaci verzí, které mají
v názvu dev, RC, alpha,
beta. Výchozí specifikaci stability lze přepsat konfigurací
"minimum-stability": "dev".
minimum-stability: dev se často používá v kombinaci s
"prefer-stable": true, která preferuje stable verze
balíčků a k instalaci dev verze se uchýlí pouze
v případě, že neexistuje žádná kombinace stable verzí,
která by vyhovovala požadavkům.
Composer pak pro jednotlivé balíčky hledá kandidáty, kteří vyhovují
uvedené specifikaci verze a specifikaci stability (ať již explicitní
u balíčku pomocí zavináče nebo globální na projektu pomocí
minimum-stability).
Narazil jsem na pěkný nástroj, který vám pro konkrétní balíček, version constraint a stability flag zvýrazní, které verze balíčku by composer dovolil nainstalovat.
Z výše uvedeného mi vyplývá, že pro otestování Latte 3 by mělo stačit nastavit následující omezení:
"require": {
"nette/application": "^3.1-RC@RC",
"nette/caching": "^3.1-RC@RC",
"nette/forms": "^3.1-RC@RC",
"latte/latte": "^3.0-RC@RC",
}
a nemusíte pak mít nastavenou minimum-stability.
- Marek Bartoš
- Nette Blogger | 1274
Je to… komplikované.
3.1.x-dev – stáhni větev 3.1
- .x informuje, že jde o větev a ne o tag
- -dev informuje, že jde o větev a ne o konkrétní verzi
- v případě větve
dev-example – stáhni větev example
- tato varianta nefunguje s názvy větví vypadajícími jako verze
- v tomhle případě údajně klonuje repozitář (nefunguje to však
s číselnými verzemi větví, neověřím si to)
v3.1 vs 3.1 – afaik na tom nezáleží a
composer zkouší obojí
prefer-stable
- nastavuji vždy na true, bez toho by
minimum-stability: dev instalovala dev verze u všech balíků
- jestliže je na výběr z více verzí a máme
prefer-stable: true, tak bere vždy stable verzi – nikdy dev,
RC, …
minimum-stability: dev
- může nabývat hodnot dev, alpha,
beta, RC, stable
- pokud specifikujete stabilitu explicitně, tak není vůbec potřeba ho
používat a tím pádem ani prefer-stable: true
3.1@<stability>
- preferovaná stabilita, umožňuje přebít minimum-stability
- nepřebíjí však prefer-stable, s
prefer-stable: true se při ^3.1-RC@RC nainstaluje
3.1.5 (stable), namísto 3.1.6-RC1
- např. 3.1@dev
- nefunguje moc dobře – vyloženě mi hlásí, že v3.1.6@rc je
v konfliktu s vyžadovanou verzí * téhož balíků (vyžaduju
nette/application na více místech)
3.1.6-RC1
- nainstaluje v3.1.6-RC1
^v3.1.6-RC1
- nainstaluje v3.1.6-RC1 nebo vyšší
^3.1.0
- instaluje >=3.1.0 <4.0.0
- totéž co ^3.1
~3.1.0
- instaluje >=3.1.0 <3.2.0
- není totéž co ~3.1! – v případě ~3.1 se
composer chová stejně jako u ^3.1, jinak než ostatní package
managery
3.1.x-dev#49e0a697f5dd4e551d92d67b3caedebdf60f3c0d
- nainstaluje commit
- funguje <branch>.x-dev#<commit> i
dev-#<commit>
- opět se stejnými omezeními která jsou uvedená u dev- a
-dev
- afaik nejde stáhnout commit bez specifikování větve
zda se stahuje verze bez .git a bez zbytečných souborů určuje přepínač
--prefer-source. U konkrétních balíků lze ovlivnit jen pomocí
ne vždy funkčního dev- prefixu nebo explicitně přes
nastavení repositories
Netuším, jak se specifikují tagy z konkrétní větve.
Editoval Marek Bartoš (11. 5. 2022 14:25)
- Marek Bartoš
- Nette Blogger | 1274
Editoval jsem trochu vysvětlení ohledně @<stability>
v předchozím příspěvku.
Imho je chování nejpředvídatelnější s
prefer-stable: true, minimum-stability: dev a bez
používání @<stability>, dev- prefixu a
~3.1 constraint.
Editoval Marek Bartoš (11. 5. 2022 14:40)
- Marek Bartoš
- Nette Blogger | 1274
Když je nějaký balík uzamčený na ~3.0.0 (tzn
>= 3.0.0-dev <3.1.0-dev), tak je ideální balík
aktualizovat, aby novější verzi povoloval.
Pokud však chcete omezení jen obejít a donutit Composer nainstalovat novou
verzi, tak pomůže klíčové slovo as –
3.1.6-RC1 as 3.0.0.
Toto však funguje pouze s konkrétními verzemi, ani jedna z těchto dvou
verzí nemůže být range. ^3.1.6-RC1 as 3.0.0 Composer
zamítne.
Editoval Marek Bartoš (11. 5. 2022 14:34)
- Marek Bartoš
- Nette Blogger | 1274
Pokud k verzi nespecifikujete preferovanou stabilitu (@dev),
tak si Composer interně doplní stabilitu sám,
podle minimum-stability
^3.0.0 s minimum-stability: stable se stane
>=3.0.0@stable <4.0.0@stable
^3.0.0 s minimum-stability: dev se
stane >=3.0.0@dev <4.0.0@dev
V dokumentaci uvádějí 3.0.0-dev. Vám taková syntaxe pro
stabilitu ale neprojde, Composer by ji považoval za větev.
Editoval Marek Bartoš (11. 5. 2022 14:40)
- Niro
- Člen | 6
Ahoj,
mám k tomu doplňující otázku. Reálně máme několik set balíčku,
které jsou na sobě různě závislé. Otázku tedy zjednoduším na
minimální možný příklad:
Máme aplikaci a balíčky A a
B
V balíčku A máme, že vyžaduje minimální verzi
X balíčku B
Aplikace vyžaduje konkrétní verzi X balíčku
A i balíčku B.
Existuje nějaký způsob, jak bych si během vývoje mohl do aplikace stáhnout konkrétní dev-větev balíčku B aniž bych musel jít do balíčku A a zmírnit omezení?
- Niro
- Člen | 6
@MarekBartoš Mockrát díky! O aliasech jsem nevěděl a dnes jsem to tu přehlídl. To že jde composer takhle oblbnout je přesně to co potřebujeme pro vývoj. Doteď jsme museli mít ve všech balíčcích všechny naše další závislosti jako hvězdičku, protože jinak jsme je nemohli v aplikaci natáhnout v dev-větev verzi.