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.

Syntax und Abgleichverhalten der Paketgruppendefinition

Dieses Thema enthält Informationen zur Definition von Paketgruppen, zum Verhalten beim Mustervergleich, zur Stärke der Paketzuordnungen und zur Paketgruppenhierarchie.

Syntax und Beispiele für Paketgruppendefinitionen

Die Mustersyntax für die Definition von Paketgruppen folgt weitgehend der Formatierung von Paketpfaden. Ein Paketpfad wird aus den Koordinatenkomponenten eines Pakets (Format, Namespace und Name) erstellt, indem am Anfang ein Schrägstrich hinzugefügt und die einzelnen Komponenten durch einen Schrägstrich getrennt werden. Der Paketpfad für das im Namespace-Space benannte npm-Paket lautet beispielsweise anycompany-ui-components/npm/space/. anycompany-ui-components

Ein Paketgruppenmuster folgt derselben Struktur wie ein Paketpfad, mit der Ausnahme, dass Komponenten, die nicht als Teil der Gruppendefinition angegeben sind, weggelassen werden und das Muster mit einem Suffix abgeschlossen wird. Das enthaltene Suffix bestimmt das Übereinstimmungsverhalten des Musters wie folgt:

Hier sind Beispielmuster für jede der zulässigen Kombinationen:

Wie in den obigen Beispielen gezeigt, wird das ~ Suffix am Ende eines Namespaces oder Namens hinzugefügt, um eine Präfixübereinstimmung darzustellen. Es * steht hinter einem Schrägstrich, wenn es verwendet wird, um alle Werte für die nächste Komponente im Pfad abzugleichen (entweder alle Formate, alle Namespaces oder alle Namen).

Definition und Normalisierung von Paketgruppen

CodeArtifact normalisiert Python NuGet - und Swift-Paketnamen und normalisiert Swift-Paketnamespaces, bevor sie gespeichert werden. CodeArtifact verwendet diese normalisierten Namen, wenn Pakete mit Paketgruppendefinitionen abgeglichen werden. Daher müssen Paketgruppen, die einen Namespace oder Namen in diesen Formaten enthalten, den normalisierten Namespace und Namen verwenden. Weitere Informationen darüber, wie die Paketnamen und Namespaces normalisiert werden, finden Sie in der NuGetDokumentation zur Namensnormalisierung von Python und Swift.

Namespaces in Paketgruppendefinitionen

Bei Paketen oder Paketformaten ohne Namespace (Python und NuGet) dürfen Paketgruppen keinen Namespace enthalten. Die Paketgruppendefinition für diese Paketgruppen enthält einen leeren Namespace-Abschnitt. Der Pfad für das Python-Paket mit dem Namen requests lautet beispielsweise /python//requests.

Bei Paketen oder Paketformaten mit einem Namespace (Maven, Generic und Swift) muss der Namespace enthalten sein, wenn der Paketname enthalten ist. Für das Swift-Paketformat wird der normalisierte Paket-Namespace verwendet. Weitere Hinweise zur Normalisierung von Swift-Paketnamespaces finden Sie unter. Schnelle Normalisierung von Paketnamen und Namespaces

Paketgruppenhierarchie und Musterspezifität

Die Pakete, die sich in einer Paketgruppe befinden oder ihr „zugeordnet“ sind, sind Pakete mit einem Paketpfad, der dem Muster der Gruppe entspricht, aber nicht dem Muster einer spezifischeren Gruppe entspricht. Wenn beispielsweise die Paketgruppen /npm/* und angegeben sind/npm/space/*, ist der Paketpfad /npm//react der ersten Gruppe (/npm/*) zugeordnet, während /npm/space/aui.components und /npm/space/ der zweiten Gruppe () zugeordnet sind. amplify-ui-core /npm/space/* Auch wenn ein Paket mehreren Gruppen entsprechen kann, ist jedes Paket nur einer einzigen Gruppe zugeordnet, wobei die spezifischste Gruppe zutrifft, und nur die Konfiguration dieser einen Gruppe gilt für das Paket.

Wenn ein Paketpfad mehreren Mustern entspricht, kann das „spezifischere“ Muster als das am längsten übereinstimmende Muster angesehen werden. Alternativ ist das spezifischere Muster dasjenige, das einer richtigen Teilmenge der Pakete entspricht, die dem weniger spezifischen Muster entsprechen. Aus unserem vorherigen Beispiel geht hervor, dass jedes Paket, das übereinstimmt/npm/*, /npm/space/* auch übereinstimmt, aber das Gegenteil ist nicht der Fall, weshalb /npm/space/* das Muster spezifischer ist, weil es eine richtige Teilmenge von ist. /npm/* Da es sich bei einer Gruppe um eine Teilmenge einer anderen Gruppe handelt, entsteht eine Hierarchie, in der /npm/space/* sich eine Untergruppe der übergeordneten Gruppe befindet. /npm/*

Obwohl nur die Konfiguration der spezifischsten Paketgruppe für ein Paket gilt, kann diese Gruppe so konfiguriert werden, dass sie von der Konfiguration der übergeordneten Gruppe erbt.

Wörter, Wortgrenzen und Präfixabgleich

Bevor wir uns mit dem Präfixabgleich befassen, wollen wir einige Schlüsselbegriffe definieren:

Insbesondere lautet das Regex-Muster für ein Wort[\p{L}\p{N}][\p{L}\p{N}\p{M}]*, das wie folgt aufgeteilt werden kann:

Steht daher [\p{L}\p{N}] für eine Zahl oder einen Buchstaben und [\p{L}\p{N}\p{M}]* steht für null oder mehr Buchstaben, Zahlen oder Markierungszeichen, und am Ende jeder Übereinstimmung dieses Regex-Musters befindet sich eine Wortgrenze.

Nachdem das Wort und die Wortgrenze nun definiert sind, können wir sie verwenden, um den Präfixabgleich in zu beschreiben CodeArtifact. Um anzugeben, dass ein Präfix an einer Wortgrenze übereinstimmt, wird nach einem Wortzeichen ein Übereinstimmungszeichen (~) verwendet. Das Muster /npm/space/foo~ entspricht beispielsweise den Paketpfaden /npm/space/foo und/npm/space/foo-bar, aber nicht /npm/space/food oder/npm/space/foot.

Ein Platzhalter (*) muss anstelle von verwendet werden, ~ wenn einem Zeichen gefolgt wird, das kein Wort ist, wie im Muster. /npm/*

Groß-/Kleinschreibung

Bei Paketgruppendefinitionen wird zwischen Groß- und Kleinschreibung unterschieden, was bedeutet, dass Muster, die sich nur durch die Groß- und Kleinschreibung unterscheiden, als separate Paketgruppen existieren können. Beispielsweise kann ein Benutzer separate Paketgruppen mit den Mustern und /npm//asyncstorage$ für die drei separaten Pakete /npm//AsyncStorage$/npm//asyncStorage$, die in der öffentlichen Registrierung von npm vorhanden sind, erstellen: AsyncStorage,, asyncstorage asyncStorage, die sich nur durch Groß- und Kleinschreibung unterscheiden.

Auch wenn die Groß- und Kleinschreibung wichtig ist, ordnet man Pakete CodeArtifact trotzdem einer Paketgruppe zu, wenn das Paket eine Variante des Musters hat, die sich von Fall zu Fall unterscheidet. Wenn ein Benutzer die /npm//AsyncStorage$ Paketgruppe erstellt, ohne die anderen beiden oben aufgeführten Gruppen zu erstellen, werden alle Varianten des Namens zwischen Groß asyncStorage- und Kleinschreibung AsyncStorage, einschließlich und asyncstorage, der Paketgruppe zugeordnet. Wie im nächsten Abschnitt beschriebenStarkes und schwaches Spiel, werden diese Variationen jedoch anders behandelt als das AsyncStorage, was genau dem Muster entspricht.

Starkes und schwaches Spiel

Die Informationen im vorherigen Abschnitt,, besagenGroß-/Kleinschreibung, dass bei Paketgruppen zwischen Groß- und Kleinschreibung unterschieden wird. Anschließend wird erklärt, dass sie nicht zwischen Groß- und Kleinschreibung unterscheiden. Das liegt daran, dass in CodeArtifact Paketgruppendefinitionen ein Konzept von starker Übereinstimmung (oder exakter Übereinstimmung) und schwacher Übereinstimmung (oder Variantenübereinstimmung) verwendet wird. Eine starke Übereinstimmung liegt vor, wenn das Paket dem Muster exakt und ohne jegliche Variation entspricht. Eine schwache Übereinstimmung liegt vor, wenn das Paket einer Variante des Musters entspricht, z. B. einer anderen Groß- und Kleinschreibung. Das Verhalten bei schwacher Übereinstimmung verhindert, dass Pakete, bei denen es sich um Varianten des Musters einer Paketgruppe handelt, zu einer allgemeineren Paketgruppe zusammengefasst werden. Wenn es sich bei einem Paket um eine Variante (schwache Übereinstimmung) des Musters handelt, das am genauesten zu der Gruppe passt, wird das Paket zwar der Gruppe zugeordnet, aber das Paket wird blockiert, anstatt die Konfiguration der Ursprungsverwaltung der Gruppe anzuwenden, wodurch verhindert wird, dass neue Versionen des Pakets aus Upstreams abgerufen oder veröffentlicht werden. Dieses Verhalten reduziert das Risiko von Angriffen auf die Lieferkette, die aus einer Verwechselung der Abhängigkeiten von Paketen mit nahezu identischen Namen resultieren.

Um das Verhalten bei schwachen Übereinstimmungen zu veranschaulichen, nehmen wir an, dass die Paketgruppe die Aufnahme /npm/* zulässt und die Veröffentlichung blockiert. Eine spezifischere Paketgruppe,, ist so konfiguriert/npm//anycompany-spicy-client$, dass sie die Aufnahme blockiert und die Veröffentlichung ermöglicht. Das angegebene anycompany-spicy-clientPaket entspricht stark der Paketgruppe, die die Veröffentlichung von Paketversionen ermöglicht und die Aufnahme von Paketversionen blockiert. Die einzige Groß-/Kleinschreibung des Paketnamens, der veröffentlicht werden darf anycompany-spicy-client, ist, weil er dem Muster der Paketdefinition sehr gut entspricht. Bei einer anderen Variante von Groß- und Kleinschreibung, z. B. AnyCompany-spicy-client, ist die Veröffentlichung gesperrt, da es sich um eine schwache Übereinstimmung handelt. Noch wichtiger ist, dass die Paketgruppe die Aufnahme aller Varianten von Groß- und Kleinschreibung blockiert, nicht nur des im Muster verwendeten Kleinbuchstabennamens, wodurch das Risiko einer Konfusion von Abhängigkeiten verringert wird.

Zusätzliche Varianten

Neben Unterschieden zwischen Groß- und Kleinschreibung werden beim schwachen Abgleich auch Unterschiede in der Reihenfolge von Bindestrichen-, Punkten ._, Unterstrichen und verwechselbaren Zeichen (z. B. ähnlich aussehende Zeichen aus unterschiedlichen Alphabeten) ignoriert. Bei der Normalisierung, die für schwache Übereinstimmungen verwendet wird, wird Groß- und Kleinschreibung (ähnlich der Konvertierung in Kleinbuchstaben) CodeArtifact durchgeführt, Abfolgen von Bindestrich-, Punkt- und Unterstrichzeichen durch einen einzelnen Punkt ersetzt und verwirrende Zeichen normalisiert.

Bei schwachem Abgleich werden Bindestriche, Punkte und Unterstriche als gleichwertig behandelt, aber nicht vollständig ignoriert. Das bedeutet, dass foo-bar, foo.bar, foo.. bar und foo_bar allesamt schwache Match-Entsprechungen sind, foobar jedoch nicht. Obwohl mehrere öffentliche Repositorien Maßnahmen ergreifen, um diese Art von Variationen zu verhindern, macht der Schutz, den öffentliche Repositorien bieten, diese Funktion von Paketgruppen nicht unnötig. Beispielsweise verhindern öffentliche Repositorien wie die Registrierung für die öffentliche Registrierung von npm nur dann neue Varianten des Pakets mit dem Namen my-package, wenn my-package dort bereits veröffentlicht ist. Wenn my-package ein internes Paket ist und eine Paketgruppe erstellt /npm//my-package$ wird, die die Veröffentlichung ermöglicht und die Aufnahme blockiert, möchten Sie my-package wahrscheinlich nicht in der öffentlichen Registrierung von npm veröffentlichen, um zu verhindern, dass eine Variante wie my.package zugelassen wird.

Während einige Paketformate wie Maven diese Zeichen unterschiedlich behandeln (Maven behandelt sie als Trennzeichen für die Namespace-Hierarchie, aber nicht - oder_), könnte etwas . wie com.act-on dennoch mit com.act.on verwechselt werden.