Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Sintassi della definizione del gruppo di pacchetti e comportamento di abbinamento

Questo argomento contiene informazioni sulla definizione dei gruppi di pacchetti, sul comportamento di corrispondenza dei modelli, sulla forza dell'associazione dei pacchetti e sulla gerarchia dei gruppi di pacchetti.

Sintassi ed esempi per la definizione dei gruppi di pacchetti

La sintassi del modello per definire i gruppi di pacchetti segue da vicino la formattazione dei percorsi dei pacchetti. Il percorso del pacchetto viene creato a partire dai componenti delle coordinate di un pacchetto (formato, namespace e nome) aggiungendo una barra all'inizio e separando ciascun componente con una barra. Ad esempio, il percorso del pacchetto npm denominato anycompany-ui-componentsnello spazio dei nomi è /npm/space/. anycompany-ui-components

Un modello di gruppo di pacchetti segue la stessa struttura di un percorso di pacchetto, tranne i componenti che non sono specificati come parte della definizione del gruppo vengono omessi e il modello termina con un suffisso. Il suffisso incluso determina il comportamento di corrispondenza del pattern, nel modo seguente:

Ecco alcuni modelli di esempio per ciascuna delle combinazioni consentite:

Come illustrato negli esempi precedenti, il ~ suffisso viene aggiunto alla fine di uno spazio dei nomi o di un nome per rappresentare una corrispondenza di prefisso e * viene dopo una barra se utilizzato per abbinare tutti i valori del componente successivo nel percorso (tutti i formati, tutti gli spazi dei nomi o tutti i nomi).

Definizione e normalizzazione del gruppo di pacchetti

CodeArtifact normalizza i NuGet nomi dei pacchetti Python e Swift e normalizza i namespace dei pacchetti Swift prima di archiviarli. CodeArtifact usa questi nomi normalizzati per abbinare i pacchetti alle definizioni dei gruppi di pacchetti. Pertanto, i gruppi di pacchetti che contengono uno spazio dei nomi o un nome in questi formati devono utilizzare lo spazio dei nomi e il nome normalizzati. Per ulteriori informazioni su come vengono normalizzati i nomi dei pacchetti e gli spazi dei nomi, consulta la documentazione sulla normalizzazione dei nomi di NuGetPython e Swift.

Namespace nelle definizioni dei gruppi di pacchetti

Per pacchetti o formati di pacchetti senza uno spazio dei nomi (Python e NuGet), i gruppi di pacchetti non devono contenere uno spazio dei nomi. La definizione del gruppo di pacchetti per questi gruppi di pacchetti contiene una sezione dello spazio dei nomi vuota. Ad esempio, il percorso per il pacchetto Python denominato requests è /python//requests.

Per i pacchetti o i formati di pacchetto con uno spazio dei nomi (Maven, generic e Swift), lo spazio dei nomi deve essere incluso se è incluso il nome del pacchetto. Per il formato del pacchetto Swift, verrà utilizzato lo spazio dei nomi dei pacchetti normalizzato. Per ulteriori informazioni su come vengono normalizzati gli spazi dei nomi dei pacchetti Swift, consulta. Normalizzazione del nome e dello spazio dei nomi del pacchetto Swift

Gerarchia dei gruppi di pacchetti e specificità del modello

I pacchetti che sono «in» o «associati a» un gruppo di pacchetti sono pacchetti con un percorso di pacchetto che corrisponde allo schema del gruppo ma non corrisponde allo schema di un gruppo più specifico. Ad esempio, dati i gruppi di pacchetti /npm/* and/npm/space/*, il percorso del pacchetto /npm//react è associato al primo gruppo (/npm/*) mentre /npm/space/aui.components e /npm/space/ sono associati al secondo gruppo (). amplify-ui-core /npm/space/* Anche se un pacchetto può corrispondere a più gruppi, ogni pacchetto è associato solo a un singolo gruppo, la corrispondenza più specifica, e solo la configurazione di quel gruppo si applica al pacchetto.

Quando il percorso di un pacchetto corrisponde a più modelli, il modello «più specifico» può essere considerato il modello di corrispondenza più lungo. In alternativa, il modello più specifico è quello che corrisponde a un sottoinsieme appropriato dei pacchetti che corrispondono al modello meno specifico. Nel nostro esempio precedente, ogni pacchetto che corrisponde corrisponde /npm/space/* anche/npm/*, ma non è vero il contrario, il che rende /npm/space/* il modello più specifico perché è un sottoinsieme appropriato di. /npm/* Poiché un gruppo è un sottoinsieme di un altro gruppo, crea una gerarchia, in cui si /npm/space/* trova un sottogruppo del gruppo principale,. /npm/*

Sebbene a un pacchetto si applichi solo la configurazione del gruppo di pacchetti più specifico, tale gruppo può essere configurato per ereditare dalla configurazione del gruppo principale.

Parole, confini delle parole e corrispondenza dei prefissi

Prima di parlare della corrispondenza dei prefissi, definiamo alcuni termini chiave:

In particolare, lo schema regex di una parola è[\p{L}\p{N}][\p{L}\p{N}\p{M}]*, che può essere suddiviso come segue:

Pertanto, [\p{L}\p{N}] rappresenta un numero o una lettera e [\p{L}\p{N}\p{M}]* rappresenta zero o più lettere, numeri o caratteri distintivi e un limite di parola si trova alla fine di ogni corrispondenza di questo modello regex.

Ora che la parola e il limite della parola sono definiti, possiamo usarli per descrivere la corrispondenza dei prefissi in. CodeArtifact Per indicare una corrispondenza di prefisso sul confine di una parola, dopo un carattere di parola viene utilizzato un carattere di corrispondenza (~). Ad esempio, il modello /npm/space/foo~ corrisponde ai percorsi dei pacchetti /npm/space/foo e/npm/space/foo-bar, ma non /npm/space/food a or. /npm/space/foot

È necessario utilizzare un carattere jolly (*) al posto di ~ quando si segue un carattere non verbale, come nel pattern. /npm/*

Distinzione tra lettere maiuscole e minuscole

Le definizioni dei gruppi di pacchetti fanno distinzione tra maiuscole e minuscole, il che significa che modelli che differiscono solo per maiuscole e minuscole possono esistere come gruppi di pacchetti separati. Ad esempio, un utente può creare gruppi di pacchetti separati con i modelli /npm//AsyncStorage$ e /npm//asyncstorage$ per i tre pacchetti separati esistenti nel registro pubblico di npm: AsyncStorage, asyncStorage, asyncstorage che differiscono solo per maiuscole e minuscole. /npm//asyncStorage$

Sebbene i casi siano importanti, associa CodeArtifact comunque i pacchetti a un gruppo di pacchetti se il pacchetto presenta una variazione del modello che differisce da caso a caso. Se un utente crea il gruppo di /npm//AsyncStorage$ pacchetti senza creare gli altri due gruppi mostrati sopra, tutte le varianti maiuscole asyncStoragee minuscole del nome AsyncStorage, inclusa asyncstorage, verranno associate al gruppo di pacchetti. Tuttavia, come descritto nella sezione successivaPartita forte e debole, queste variazioni verranno gestite in modo diverso rispetto a AsyncStorage, il che corrisponde esattamente allo schema.

Partita forte e debole

Le informazioni nella sezione precedenteDistinzione tra lettere maiuscole e minuscole, affermano che i gruppi di pacchetti fanno distinzione tra maiuscole e minuscole, e poi proseguono spiegando che non fanno distinzione tra maiuscole e minuscole. Questo perché le definizioni dei gruppi di pacchetti CodeArtifact hanno un concetto di corrispondenza forte (o corrispondenza esatta) e di corrispondenza debole (o corrispondenza di variazione). Una forte corrispondenza si ha quando il pacchetto corrisponde esattamente allo schema, senza alcuna variazione. Una corrispondenza debole si verifica quando il pacchetto corrisponde a una variante dello schema, ad esempio lettere maiuscole diverse. Un comportamento di corrispondenza debole impedisce ai pacchetti che sono variazioni dello schema di un gruppo di pacchetti di passare a un gruppo di pacchetti più generale. Quando un pacchetto è una variante (weak match) del pattern del gruppo corrispondente più specifico, il pacchetto viene associato al gruppo ma il pacchetto viene bloccato invece di applicare la configurazione di controllo dell'origine del gruppo, impedendo che qualsiasi nuova versione del pacchetto venga estratta dai flussi iniziali o pubblicata. Questo comportamento riduce il rischio di attacchi alla catena di approvvigionamento derivanti dalla confusione delle dipendenze di pacchetti con nomi quasi identici.

Per illustrare un comportamento debole, supponiamo che il gruppo di pacchetti /npm/* consenta l'ingestione e blocchi la pubblicazione. Un gruppo di pacchetti più specifico/npm//anycompany-spicy-client$, è configurato per bloccare l'ingestione e consentire la pubblicazione. Il pacchetto denominato anycompany-spicy-clientcorrisponde perfettamente al gruppo di pacchetti, che consente la pubblicazione delle versioni del pacchetto e blocca l'acquisizione delle versioni del pacchetto. L'unico maiuscolo del nome del pacchetto che può essere pubblicato è anycompany-spicy-client, poiché corrisponde perfettamente al modello di definizione del pacchetto. Una variante diversa tra maiuscole e minuscole, come AnyCompany-spicy-client, è bloccata dalla pubblicazione perché non corrisponde a nulla. Ancora più importante, il gruppo di pacchetti blocca l'inserimento di tutte le varianti tra maiuscole e minuscole, non solo del nome in minuscolo utilizzato nel modello, riducendo il rischio di un attacco di confusione delle dipendenze.

Varianti aggiuntive

Oltre alle differenze tra maiuscole e minuscole, la corrispondenza debole ignora anche le differenze nelle sequenze di trattini-, punti., _ trattini bassi e caratteri confondibili (ad esempio caratteri dall'aspetto simile di alfabeti separati). Durante la normalizzazione, utilizzata per la corrispondenza debole, CodeArtifact esegue la piegatura tra maiuscole e minuscole (simile alla conversione in minuscolo), sostituisce le sequenze di caratteri con trattini, punti e sottolineature con un singolo punto e normalizza i caratteri confondibili.

La corrispondenza debole considera trattini, punti e caratteri di sottolineatura come equivalenti ma non li ignora completamente. Ciò significa che foo-bar, foo.bar, foo.. bar e foo_bar sono tutti equivalenti a match deboli, ma foobar no. Sebbene diversi archivi pubblici implementino misure per prevenire questo tipo di variazioni, la protezione fornita dagli archivi pubblici non rende superflua questa funzionalità dei gruppi di pacchetti. Ad esempio, gli archivi pubblici come il registro npm Public Registry impediranno nuove varianti del pacchetto denominato my-package solo se my-package è già stato pubblicato su di esso. Se my-package è un pacchetto interno e /npm//my-package$ viene creato un gruppo di pacchetti che consente la pubblicazione e blocca l'ingestione, probabilmente non vorrai pubblicare my-package nel registro pubblico di npm per impedire che una variante come my.package sia consentita.

Sebbene alcuni formati di pacchetti come Maven trattino questi caratteri in modo diverso (Maven lo tratta . come un separatore della gerarchia dei namespace ma non - or_), qualcosa come com.act-on potrebbe comunque essere confuso con com.act.on.