Jak testovat -dev verze balíčků s Composerem?

David Grudl
Nette Core | 7769
+
+2
-

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 | 262
+
+5
-

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-bugfix nebo 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 | 682
+
+3
-

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. 14:25)

Marek Bartoš
Nette Blogger | 682
+
+1
-

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. 14:40)

Marek Bartoš
Nette Blogger | 682
+
+1
-

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. 14:34)

Marek Bartoš
Nette Blogger | 682
+
0
-

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. 14:40)

Niro
Člen | 6
+
0
-

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
+
0
-

@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.