Amazon non CodeCatalyst è più aperto a nuovi clienti. I clienti esistenti possono continuare a utilizzare il servizio normalmente. Per ulteriori informazioni, consulta Come migrare da CodeCatalyst.
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à.
Concetti relativi ai pacchetti
Ecco alcuni concetti e termini da conoscere per gestire, pubblicare o consumare pacchetti in CodeCatalyst.
Pacchetti
Un pacchetto è un pacchetto che include sia il software che i metadati necessari per installare il software e risolvere eventuali dipendenze. CodeCatalyst supporta il formato del pacchetto npm.
Un pacchetto è composto da:
-
Un nome (ad esempio,
webpackè il nome di un popolare pacchetto npm) -
Un namespace opzionale (ad esempio, in)
@types@types/node -
Un set di versioni (ad esempio,
1.0.0,1.0.1)1.0.2 -
Package-level metadati (ad esempio, tag npm dist)
namespace dei pacchetti
Alcuni formati di pacchetto supportano nomi di pacchetti gerarchici per organizzare i pacchetti in gruppi logici e per evitare conflitti di nomi. I pacchetti con lo stesso nome possono essere memorizzati in namespace diversi. Ad esempio, npm supporta gli ambiti e il pacchetto npm @types/node ha un ambito e un nome di. @types node Ci sono molti altri nomi di pacchetti nell'ambito. @types In CodeCatalyst, l'ambito («tipi») è indicato come namespace del pacchetto e il nome («nodo») è indicato come nome del pacchetto. Per i pacchetti Maven, lo spazio dei nomi del pacchetto corrisponde al GroupID Maven. Il pacchetto Maven org.apache.logging.log4j:log4j ha un groupID (spazio dei nomi del pacchetto) e un artifactID (nome del pacchetto). org.apache.logging.log4j log4j Alcuni formati di pacchetto come Python non supportano nomi gerarchici con un concetto simile a npm scope o Maven GroupId. Se non si dispone di un modo per raggruppare i nomi dei pacchetti, può essere più difficile evitare le collisioni di nomi.
Versioni del pacchetto
Una versione del pacchetto identifica la versione specifica di un pacchetto, ad esempio. @types/node@12.6.9 Il formato e la semantica del numero di versione variano a seconda dei diversi formati di pacchetto. Ad esempio, le versioni del pacchetto npm devono essere conformi alla specifica Semantic Versioning. https://semver.org/
Asset
Una risorsa è un singolo file archiviato in CodeCatalyst cui è associato a una versione del pacchetto, ad esempio un file npm .tgz o un file Maven POM o JAR.
Repository di pacchetti
Un repository di CodeCatalyst pacchetti contiene un set di pacchetti, che contengono le versioni dei pacchetti, ognuno dei quali è mappato a un insieme di risorse. I repository di pacchetti sono poliglotti, il che significa che un singolo repository può contenere pacchetti di qualsiasi tipo supportato. Ogni repository di pacchetti espone gli endpoint per il recupero e la pubblicazione di pacchetti utilizzando strumenti come le CLI (,), la NuGet CLInuget, la CLI di Maven (dotnet) e le npm CLI di Python (and). mvn pip twine Per informazioni sulle quote dei pacchetti in, incluso il numero di repository di pacchetti che possono essere CodeCatalyst creati in ogni spazio, vedi. Quote per i pacchetti
È possibile collegare un repository di pacchetti a un altro impostandolo come upstream. Quando un repository è impostato come upstream, puoi utilizzare qualsiasi pacchetto dell'upstream e qualsiasi repository upstream aggiuntivo nella catena. Per ulteriori informazioni, consulta Repository upstream.
I repository gateway sono un tipo speciale di repository di pacchetti che estrae e archivia i pacchetti dalle autorità esterne ufficiali dei pacchetti. Per ulteriori informazioni, consulta Repository di gateway.
Repository upstream
È possibile utilizzarlo CodeCatalyst per creare una relazione upstream tra due repository di pacchetti. Un repository di pacchetti è un upstream di un altro quando è possibile accedere alle versioni del pacchetto che contiene dall'endpoint del repository di pacchetti del repository downstream. Con una relazione upstream, i contenuti dei due repository di pacchetti vengono effettivamente uniti dal punto di vista di un cliente.
Ad esempio, se un gestore di pacchetti richiede una versione del pacchetto che non esiste in un repository, CodeCatalyst cercherà la versione del pacchetto nei repository upstream configurati. La ricerca nei repository upstream viene eseguita nell'ordine in cui sono configurati e, una volta trovato un pacchetto, la ricerca viene interrotta. CodeCatalyst
Repository di gateway
Un gateway repository è un tipo speciale di repository di pacchetti connesso a un'autorità di pacchetto ufficiale esterna supportata. Quando aggiungi un repository gateway come repository upstream, puoi consumare pacchetti dall'autorità ufficiale corrispondente per i pacchetti. Il tuo repository downstream non comunica con il repository pubblico, ma tutto è intermediato dal gateway repository. I pacchetti utilizzati in questo modo vengono archiviati sia nel repository gateway che nel repository downstream che ha ricevuto la richiesta originale.
I repository gateway sono predefiniti, ma devono essere creati in ogni progetto per essere utilizzati. L'elenco seguente contiene tutti i repository gateway che possono essere creati CodeCatalyst e l'autorità del pacchetto a cui sono connessi.
-
npm-public-registry-gateway fornisce pacchetti npm da npmjs.com.
-
maven-central-gateway fornisce pacchetti Maven dal repository Maven Central.
-
google-android-gateway fornisce pacchetti Maven di Google Android.
-
commonsware-gateway fornisce pacchetti CommonsWare Maven da.
-
gradle-plugins-gateway fornisce pacchetti Maven di Gradle Plugins.
-
nuget-gallery-gateway fornisce NuGet pacchetti NuGet dalla Galleria.
-
pypi-gateway fornisce pacchetti Python dal Python Package Index.