Konzepte für Pakete - Amazon CodeCatalyst

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Konzepte für Pakete

Im Folgenden finden Sie einige Konzepte und Begriffe, die Sie bei der Verwaltung, Veröffentlichung oder Nutzung von Paketen kennen sollten CodeCatalyst.

Pakete

Ein Paket ist ein Paket, das sowohl Software als auch die Metadaten enthält, die für die Installation der Software und die Auflösung aller Abhängigkeiten erforderlich sind. CodeCatalyst unterstützt das npm-Paketformat.

Ein Paket besteht aus:

  • Ein Name (webpackist zum Beispiel der Name eines beliebten npm-Pakets)

  • Ein optionaler Namespace (zum Beispiel in) @types @types/node

  • Eine Reihe von Versionen (zum Beispiel, 1.0.01.0.1,1.0.2)

  • Metadaten auf Paketebene (z. B. npm dist-Tags)

Paket-Namespaces

Einige Paketformate unterstützen hierarchische Paketnamen, um Pakete in logische Gruppen zu organisieren und Namenskollisionen zu vermeiden. Pakete mit demselben Namen können in verschiedenen Namespaces gespeichert werden. Beispielsweise unterstützt npm Bereiche, und das npm-Paket @types/node hat den Bereich und den Namen. @types node Es gibt viele andere Paketnamen im Gültigkeitsbereich. @types CodeCatalystIn wird der Bereich („Typen“) als Paket-Namespace und der Name („Knoten“) als Paketname bezeichnet. Bei Maven-Paketen entspricht der Paket-Namespace der Maven-GroupID. Das Maven-Paket org.apache.logging.log4j:log4j hat eine GroupID (Paket-Namespace) von org.apache.logging.log4j und die ArtifactID (Paketname). log4j Einige Paketformate wie Python unterstützen keine hierarchischen Namen mit einem ähnlichen Konzept wie npm scope oder Maven GroupID. Wenn Sie keine Möglichkeit haben, Paketnamen zu gruppieren, kann es schwieriger sein, Namenskollisionen zu vermeiden.

Paketversionen

Eine Paketversion identifiziert die spezifische Version eines Pakets, z. @types/node@12.6.9 B. Das Format und die Semantik der Versionsnummer variieren je nach Paketformat. Beispielsweise müssen npm-Paketversionen der Semantic Versioning-Spezifikation entsprechen. In CodeCatalyst besteht eine Paketversion aus der Versionskennung, package-version-level Metadaten und einer Reihe von Assets.

Objekte

Ein Asset ist eine einzelne Datei CodeCatalyst , die in einer Paketversion gespeichert ist, z. B. eine .tgz NPM-Datei oder eine Maven- POM oder JAR Datei.

Paket-Repositorys

Ein CodeCatalyst Paket-Repository enthält eine Reihe von Paketen, die Paketversionen enthalten, von denen jede einer Reihe von Assets zugeordnet ist. Paket-Repositorys sind polyglot, was bedeutet, dass ein einzelnes Repository Pakete aller unterstützten Typen enthalten kann. Jedes Paket-Repository stellt Endpunkte zum Abrufen und Veröffentlichen von Paketen mit Tools wie NuGet CLIs (nuget,dotnet), The npmCLI, Maven CLI (mvn) und Python CLIs (und) zur Verfügung. pip twine Informationen zu Paketkontingenten in CodeCatalyst, einschließlich der Anzahl der Paket-Repositorys, die in jedem Bereich erstellt werden können, finden Sie unter. Kontingente für Pakete

Sie können ein Paket-Repository mit einem anderen verknüpfen, indem Sie es als Upstream-Repository einrichten. Wenn ein Repository als Upstream-Repository festgelegt ist, können Sie jedes Paket aus dem Upstream-Repository sowie alle zusätzlichen Upstream-Repositorys in der Kette verwenden. Weitere Informationen finden Sie unter Upstream-Repositorien.

Gateway-Repositorien sind eine spezielle Art von Paket-Repositorys, die Pakete von offiziellen externen Paketbehörden abrufen und speichern. Weitere Informationen finden Sie unter Gateway-Repositorys.

Upstream-Repositorien

Sie können CodeCatalyst es verwenden, um eine Upstream-Beziehung zwischen zwei Paket-Repositorys herzustellen. Ein Paket-Repository ist ein Upstream-Repository eines anderen, wenn auf die darin enthaltenen Paketversionen vom Paket-Repository-Endpunkt des Downstream-Repositorys aus zugegriffen werden kann. Bei einer Upstream-Beziehung werden die Inhalte der beiden Paket-Repositorien aus Sicht eines Kunden effektiv zusammengeführt.

Wenn ein Paketmanager beispielsweise eine Paketversion anfordert, die in einem Repository nicht existiert, durchsucht er CodeCatalyst dann konfigurierte Upstream-Repositorys nach der Paketversion. Upstream-Repositorys werden in der Reihenfolge durchsucht, in der sie konfiguriert wurden. Sobald ein Paket gefunden wurde, CodeCatalyst wird die Suche beendet.

Gateway-Repositorys

Ein Gateway-Repository ist eine spezielle Art von Paket-Repository, das mit einer unterstützten externen, offiziellen Paketautorität verbunden ist. Wenn Sie ein Gateway-Repository als Upstream-Repository hinzufügen, können Sie Pakete von der entsprechenden offiziellen Paketbehörde verwenden. Ihr Downstream-Repository kommuniziert nicht mit dem öffentlichen Repository, sondern alles wird vom Gateway-Repository vermittelt. Auf diese Weise verbrauchte Pakete werden sowohl im Gateway-Repository als auch im Downstream-Repository gespeichert, das die ursprüngliche Anfrage erhalten hat.

Gateway-Repositorys sind vordefiniert, müssen aber in jedem Projekt erstellt werden, damit sie verwendet werden können. Die folgende Liste enthält alle Gateway-Repositorys, in denen sie erstellt werden können, CodeCatalyst sowie die Package Authority, mit der sie verbunden sind.

  • npm-public-registry-gatewaystellt npm-Pakete von npmjs.com bereit.

  • maven-central-gatewaystellt Maven-Pakete aus dem Maven Central-Repository bereit.

  • google-android-gatewaybietet Maven-Pakete von Google Android.

  • commonsware-gateway bietet Maven-Pakete von. CommonsWare

  • gradle-plugins-gatewaystellt Maven-Pakete von Gradle Plugins zur Verfügung.

  • nuget-gallery-gatewaystellt NuGet Pakete aus der Galerie zur NuGet Verfügung.

  • pypi-gateway stellt Python-Pakete aus dem Python Package Index zur Verfügung.