Composer/Replace - Versionsgeschichte

Tril am 21. Juni 2014 um 17:50 Uhr

2014-06-21T17:50:44Z

Tril: /* TL;DR; */

2014-06-05T07:39:45Z

‎TL;DR;

Tril: /* TLDR */

2014-06-05T07:39:38Z

‎TLDR

Tril: /* TLDR */

2014-05-22T16:11:00Z

‎TLDR

Tril: /* TLDR */

2014-05-22T16:10:31Z

‎TLDR

Tril am 22. Mai 2014 um 16:06 Uhr

2014-05-22T16:06:38Z

Tril am 22. Mai 2014 um 16:05 Uhr

2014-05-22T16:05:22Z

Tril: Die Seite wurde neu angelegt: „{{stub}} # Wie composer mit `replace` umgeht Mit der `replace` Eigenschaft kann man festlegen, dass das eigene Paket ein fremdes Paket …“

2014-05-22T15:38:16Z

Die Seite wurde neu angelegt: „{{stub}} # Wie composer mit <code>replace</code> umgeht Mit der <code>replace</code> Eigenschaft kann man festlegen, dass das eigene Paket ein fremdes Paket …“

Neue Seite

{{stub}}

# Wie composer mit <code>replace</code> umgeht

Mit der <code>replace</code> Eigenschaft kann man festlegen, dass das eigene Paket ein fremdes Paket "ersetzt". Dafür kann es mehrere Gründe geben, der häufigste ist wohl, dass das Paket unter einem anderen Namen weiter entwickelt wird, weil bspw. der Entwickler gewechselt hat. Im Contao Kontext sieht man auch sehr viel <code>{ "replace": { "contao-legacy/my-extension": "..." } }</code>. Das sind replaces für Pakete, die über den Legacy ER2 Server in Composer bereitgestellt werden, vom Entwickler dann aber später als "echtes" Composer Paket weiter geführt werden.

Sehr weit verbreitet ist vor allem die Notation mit <code>*</code>:
<source lang="javascript">
{ "replace": { "contao-legacy/my-extension": "*" } }
</source>

Im folgenden soll erläutert werden, warum ein replace auf alle Versionen wie in dem vorhergehenden Beispiel die denkbar schlechteste Variante ist, die man sich vorstellen kann.
Dazu muss man erst ein mal verstehen, wie replace funktioniert.

Wir gehen einfach mal davon aus, wir haben die folgenden 3 Pakete:

<source lang="javascript">
{
"name": "test/old",
"version": "1.0",
"dist": {
"url": "...",
"type": "zip"
},
"source": {
"url": "...",
"type": "svn",
"reference": "master"
}
}
</source>

<source lang="javascript">
{
"name": "test/old",
"version": "1.1",
"dist": {
"url": "...",
"type": "zip"
},
"source": {
"url": "...",
"type": "svn",
"reference": "master"
}
}
</source>

<source lang="javascript">
{
"name": "test/new",
"version": "2.0",
"dist": {
"url": "...",
"type": "zip"
},
"source": {
"url": "...",
"type": "svn",
"reference": "master"
},
"replace": {
"test/old": "*"
}
}
</source>

Um die gültigen Pakete zu finden, arbeitet Composer intern mit einem Pool. In diesen Pool generiert Composer für jeden Paketnamen eine sortierte Liste der Pakete erzeugt, die für den Paketnamen gültig sind.

Für das Paket <code>test/old</code> sieht diese Liste folgend aus:

* test/old 1.0
* test/old 1.1
* test/new 2.0

Wie Composer darauf kommt, dass <code>test/new</code> in diese Liste kommt ist ganz einfach. Jedes Paket verfügt nicht nur über seinen eindeutigen Namen, sondern auch über Alias-Namen. Schaut man sich die [https://github.com/composer/composer/blob/master/src/Composer/Package/BasePackage.php#L86 BasePackage::getNames()] Methode an, wird schnell klar welche Namen für ein Paket akzeptiert werden. Abgesehen vom <code>Package::$name</code> werden auch noch alle <code>Package::$provides</code> und <code>Package::$replaces</code> als gültige Namen für das Paket betrachtet.

Unter Strich heißt dass, dass die Namensliste von <code>test/new</code> aus <code>[test/new, test/old]</code> besteht und <code>test/new</code> deshalb in der Paketliste zu <code>test/old</code> (2 Absätze zuvor) auftaucht.

# TLDR

Ein <code>{ "name": "me/my-extension", "replace": { "contao-legacy/my-extension": "*" } }</code> sorgt dafür, dass jede Version des alten Paketes, durch das neue ersetzt wird. Das bedeutet aber auch, dass eine potentiell inkompatible Version 3 von <code>me/my-extension</code> installiert wird, auch wenn mit <code>{ "require": { "contao-legacy/my-extension": "1.0" } }</code> die Version 1 von <code>contao-legacy/my-extension</code> angefordert wird.

Deshalb sollte immer <code>{ "name": "me/my-extension", "replace": { "contao-legacy/my-extension": "self.version" } }</code> verwendet werden!

← Nächstältere Version		Version vom 21. Juni 2014, 17:50 Uhr
Zeile 1:		Zeile 1:
	{{stub}}		{{stub}}
		+	[[Category:Composer]]

	__TOC__		__TOC__

@@ Zeile 117: / Zeile 117: @@
 Hätten wir jetzt allerdings ein Paket <code>test/new</code> in Version 1.2, welches als Nachfolger von <code>test/old</code> Version 1.1 fungiert, wäre wieder alles in Ordnung, weil die Version <code>1.2</code> auf die Constraint <code>~1.0</code> matched. '''Im Regelfall ist es genau dass, was wir wollen!'''
-== TL;DR; ==
+== TL;DR ==
 Ein <code>{ "name": "me/my-extension", "replace": { "contao-legacy/my-extension": "*" } }</code> sorgt dafür, dass jede Version des alten Paketes, durch das neue ersetzt wird. Das bedeutet aber auch, dass eine potentiell inkompatible Version 3 von <code>me/my-extension</code> installiert wird, auch wenn mit <code>{ "require": { "contao-legacy/my-extension": "1.0" } }</code> die Version 1 von <code>contao-legacy/my-extension</code> angefordert wird. Das schlimmste: Als Benutzer kann man (fast) nichts dagegen machen!

@@ Zeile 117: / Zeile 117: @@
 Hätten wir jetzt allerdings ein Paket <code>test/new</code> in Version 1.2, welches als Nachfolger von <code>test/old</code> Version 1.1 fungiert, wäre wieder alles in Ordnung, weil die Version <code>1.2</code> auf die Constraint <code>~1.0</code> matched. '''Im Regelfall ist es genau dass, was wir wollen!'''
-== TLDR ==
+== TL;DR; ==
 Ein <code>{ "name": "me/my-extension", "replace": { "contao-legacy/my-extension": "*" } }</code> sorgt dafür, dass jede Version des alten Paketes, durch das neue ersetzt wird. Das bedeutet aber auch, dass eine potentiell inkompatible Version 3 von <code>me/my-extension</code> installiert wird, auch wenn mit <code>{ "require": { "contao-legacy/my-extension": "1.0" } }</code> die Version 1 von <code>contao-legacy/my-extension</code> angefordert wird. Das schlimmste: Als Benutzer kann man (fast) nichts dagegen machen!

@@ Zeile 121: / Zeile 121: @@
 Ein <code>{ "name": "me/my-extension", "replace": { "contao-legacy/my-extension": "*" } }</code> sorgt dafür, dass jede Version des alten Paketes, durch das neue ersetzt wird. Das bedeutet aber auch, dass eine potentiell inkompatible Version 3 von <code>me/my-extension</code> installiert wird, auch wenn mit <code>{ "require": { "contao-legacy/my-extension": "1.0" } }</code> die Version 1 von <code>contao-legacy/my-extension</code> angefordert wird. Das schlimmste: Als Benutzer kann man (fast) nichts dagegen machen!
-Vereinfacht ausgedrückt ist ein replace nichts weiter, als ein Alias auf das definierende Paket:
+Vereinfacht ausgedrückt ist ein replace nichts weiter, als ein Alias auf das Paket in dem der replace definiert wurde:
 <pre>
@@ Zeile 128: / Zeile 128: @@
 test/old *   alias for test/new 2.0
 </pre>
 Deshalb sollte immer <code>{ "name": "me/my-extension", "replace": { "contao-legacy/my-extension": "self.version" } }</code> verwendet werden!

← Nächstältere Version		Version vom 22. Mai 2014, 16:10 Uhr
Zeile 120:		Zeile 120:

	Ein <code>{ "name": "me/my-extension", "replace": { "contao-legacy/my-extension": "*" } }</code> sorgt dafür, dass jede Version des alten Paketes, durch das neue ersetzt wird. Das bedeutet aber auch, dass eine potentiell inkompatible Version 3 von <code>me/my-extension</code> installiert wird, auch wenn mit <code>{ "require": { "contao-legacy/my-extension": "1.0" } }</code> die Version 1 von <code>contao-legacy/my-extension</code> angefordert wird. Das schlimmste: Als Benutzer kann man (fast) nichts dagegen machen!		Ein <code>{ "name": "me/my-extension", "replace": { "contao-legacy/my-extension": "*" } }</code> sorgt dafür, dass jede Version des alten Paketes, durch das neue ersetzt wird. Das bedeutet aber auch, dass eine potentiell inkompatible Version 3 von <code>me/my-extension</code> installiert wird, auch wenn mit <code>{ "require": { "contao-legacy/my-extension": "1.0" } }</code> die Version 1 von <code>contao-legacy/my-extension</code> angefordert wird. Das schlimmste: Als Benutzer kann man (fast) nichts dagegen machen!
		+
		+	Vereinfacht ausgedrückt ist ein replace nichts weiter, als ein Alias auf das definierende Paket:
		+
		+	<pre>
		+	test/old 1.0
		+	test/old 1.1
		+	test/old * alias for test/new 2.0
		+	</pre>

	Deshalb sollte immer <code>{ "name": "me/my-extension", "replace": { "contao-legacy/my-extension": "self.version" } }</code> verwendet werden!		Deshalb sollte immer <code>{ "name": "me/my-extension", "replace": { "contao-legacy/my-extension": "self.version" } }</code> verwendet werden!

← Nächstältere Version		Version vom 22. Mai 2014, 16:06 Uhr
Zeile 1:		Zeile 1:
	{{stub}}		{{stub}}
		+
		+	__TOC__

	= Wie composer mit <code>replace</code> umgeht =		= Wie composer mit <code>replace</code> umgeht =

@@ Zeile 1: / Zeile 1: @@
 {{stub}}
-# Wie composer mit <code>replace</code> umgeht
+= Wie composer mit <code>replace</code> umgeht =
 Mit der <code>replace</code> Eigenschaft kann man festlegen, dass das eigene Paket ein fremdes Paket "ersetzt". Dafür kann es mehrere Gründe geben, der häufigste ist wohl, dass das Paket unter einem anderen Namen weiter entwickelt wird, weil bspw. der Entwickler gewechselt hat. Im Contao Kontext sieht man auch sehr viel <code>{ "replace": { "contao-legacy/my-extension": "..." } }</code>. Das sind replaces für Pakete, die über den Legacy ER2 Server in Composer bereitgestellt werden, vom Entwickler dann aber später als "echtes" Composer Paket weiter geführt werden.
@@ Zeile 78: / Zeile 78: @@
 Unter Strich heißt dass, dass die Namensliste von <code>test/new</code> aus <code>[test/new, test/old]</code> besteht und <code>test/new</code> deshalb in der Paketliste zu <code>test/old</code> (2 Absätze zuvor) auftaucht.
-# TLDR
+Wir gehen davon aus, wir wollen mit <code>{ "require": { "test/old": "~1.0" } }</code> das Paket <code>test/old</code> in irgendeiner 1er Version installieren (Hinweis: <code>~1.0</code> ist gleichbedeutend mit <code>>=1,<2-dev</code>).
-Ein <code>{ "name": "me/my-extension", "replace": { "contao-legacy/my-extension": "*" } }</code> sorgt dafür, dass jede Version des alten Paketes, durch das neue ersetzt wird. Das bedeutet aber auch, dass eine potentiell inkompatible Version 3 von <code>me/my-extension</code> installiert wird, auch wenn mit <code>{ "require": { "contao-legacy/my-extension": "1.0" } }</code> die Version 1 von <code>contao-legacy/my-extension</code> angefordert wird.
+Betrachtet man jetzt die Auswertungslogik in der [https://github.com/composer/composer/blob/master/src/Composer/DependencyResolver/Pool.php#L249 Pool::computeWhatProvides()] Methode welche die Paketliste durchgeht und das höchst-versionierte (letzte) gültige Paket auswählt, kommt man zu folgendem Ergebnis:
 Deshalb sollte immer <code>{ "name": "me/my-extension", "replace": { "contao-legacy/my-extension": "self.version" } }</code> verwendet werden!

Composer/Replace - Versionsgeschichte

Tril am 21. Juni 2014 um 17:50 Uhr

Tril: /* TL;DR; */

Tril: /* TLDR */

Tril: /* TLDR */

Tril: /* TLDR */

Tril am 22. Mai 2014 um 16:06 Uhr

Tril am 22. Mai 2014 um 16:05 Uhr

Tril: Die Seite wurde neu angelegt: „{{stub}} # Wie composer mit replace umgeht Mit der replace Eigenschaft kann man festlegen, dass das eigene Paket ein fremdes Paket …“

Tril: Die Seite wurde neu angelegt: „{{stub}} # Wie composer mit `replace` umgeht Mit der `replace` Eigenschaft kann man festlegen, dass das eigene Paket ein fremdes Paket …“