Amazon non CodeCatalyst è più aperta a nuovi clienti. I clienti esistenti possono continuare a utilizzare il servizio normalmente. Per ulteriori informazioni, consulta [Come migrare da CodeCatalyst](migration.md).
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à.
# Pubblica e condividi pacchetti software in CodeCatalyst
Amazon CodeCatalyst contiene un servizio di repository di pacchetti completamente gestito che consente al team di sviluppo di archiviare e condividere in modo semplice e sicuro i pacchetti software utilizzati per lo sviluppo di applicazioni. Questi pacchetti sono archiviati in archivi di pacchetti, che vengono creati e organizzati all'interno di progetti in. CodeCatalyst
Un singolo archivio di pacchetti può memorizzare pacchetti di ogni tipo di pacchetto supportato. CodeCatalyst supporta i seguenti formati di pacchetti:
+ npm
+ Maven
+ NuGet
+ Python
I pacchetti in un archivio di pacchetti possono essere scoperti e condivisi tra i membri del progetto che contiene il repository.
Per pubblicare e utilizzare i pacchetti da un repository, configura un gestore di pacchetti per utilizzare l'endpoint (URL) del repository. È quindi possibile utilizzare il gestore di pacchetti per pubblicare i pacchetti nel repository. Puoi usare gestori di pacchetti come Maven, Gradle, npm, yarn, nuget, dotnet, pip e twine.
Puoi anche configurare i flussi di lavoro per utilizzare gli archivi di pacchetti. CodeCatalyst CodeCatalyst Per ulteriori informazioni sull'utilizzo dei pacchetti nei flussi di lavoro, consulta. [Connessione degli archivi di pacchetti ai flussi di lavoro](workflows-packages.md)
È possibile rendere i pacchetti in un repository di pacchetti disponibili per un altro repository dello stesso progetto aggiungendolo come repository upstream. Tutte le versioni dei pacchetti disponibili nell'archivio upstream sono disponibili anche nel repository downstream. Per ulteriori informazioni, consulta [Configurazione e utilizzo degli archivi upstream](packages-upstream-repositories.md).
**È possibile rendere disponibili pacchetti open source nel CodeCatalyst repository creando un tipo speciale di repository chiamato gateway.** L'upstreaming verso un repository gateway ti consente di utilizzare pacchetti da archivi pubblici popolari come npmjs.com e pypi.org e di memorizzarli automaticamente nella cache del tuo repository. CodeCatalyst Per ulteriori informazioni, consulta [Connessione a repository esterni pubblici](packages-connect-external.md).
**Topics**
+ [Concetti relativi ai pacchetti](packages-concepts.md)
+ [Configurazione e utilizzo degli archivi di pacchetti](packages-repositories.md)
+ [Configurazione e utilizzo degli archivi upstream](packages-upstream-repositories.md)
+ [Connessione a repository esterni pubblici](packages-connect-external.md)
+ [Pubblicazione e modifica di pacchetti](working-with-packages.md)
+ [Utilizzo di npm](packages-npm.md)
+ [Usare Maven](packages-maven.md)
+ [Usando NuGet](packages-nuget.md)
+ [Uso di Python](packages-python.md)
+ [Quote per i pacchi](packages-quotas.md)
# Concetti relativi ai pacchetti
Ecco alcuni concetti e termini da conoscere per la gestione, la pubblicazione o il consumo di 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)
+ Uno spazio [dei nomi](#packages-concepts-package-namespaces) opzionale (ad esempio, in) `@types` `@types/node`
+ Un insieme di [versioni](#packages-concepts-package-versions) (ad esempio,`1.0.0`,`1.0.1`) `1.0.2`
+ Metadati a livello di pacchetto (ad esempio, tag npm dist)
## Namespace dei pacchetti
Alcuni formati di pacchetti supportano nomi di pacchetto gerarchici per organizzare i pacchetti in gruppi logici e per evitare collisioni 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») viene definito spazio dei nomi del pacchetto e il nome («nodo») viene definito nome del pacchetto. Per i pacchetti Maven, lo spazio dei nomi del pacchetto corrisponde a Maven GroupID. 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 pacchetti 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/) In CodeCatalyst, una versione del pacchetto è composta dall'identificatore di versione, dai package-version-level metadati e da un set di risorse.
## Asset
Una *risorsa* è un singolo file archiviato in CodeCatalyst che è associato a una versione del pacchetto, ad esempio un file npm o un `.tgz` file Maven POM o JAR.
## Archivi di pacchetti
[Un *archivio di CodeCatalyst pacchetti* contiene un insieme di [pacchetti, che contengono [versioni](#packages-concepts-package-versions) di pacchetti](#packages-concepts-packages), ognuna delle quali è mappata a un insieme di risorse.](#packages-concepts-assets) I repository di pacchetti sono poliglotti, il che significa che un singolo repository può contenere pacchetti di qualsiasi tipo supportato. Ogni archivio di pacchetti espone gli endpoint per il recupero e la pubblicazione di pacchetti utilizzando strumenti come NuGet CLIs (`nuget`,)`dotnet`, CLI, Maven `npm` CLI () e Python `mvn` (and). CLIs `pip` `twine` Per informazioni sulle quote dei pacchetti CodeCatalyst, incluso il numero di repository di pacchetti che è possibile creare in ogni spazio, vedere. [Quote per i pacchi](packages-quotas.md)
È possibile collegare un archivio di pacchetti a un altro impostandolo come archivio upstream. Quando un repository è impostato come upstream, è possibile utilizzare qualsiasi pacchetto dell'upstream e qualsiasi altro repository upstream della catena. Per ulteriori informazioni, consulta [Archivi upstream](#packages-concepts-upstream-repositories).
I repository gateway sono un tipo speciale di repository di pacchetti che estrae e archivia pacchetti provenienti da autorità esterne ufficiali per la gestione dei pacchetti. Per ulteriori informazioni, consulta [Repository di gateway](#packages-concepts-gateway-repositories).
## Archivi upstream
È possibile utilizzarlo CodeCatalyst per creare una relazione upstream tra due repository di pacchetti. Un repository di pacchetti è a *monte* di un altro quando è possibile accedere alle versioni dei pacchetti che contiene dall'endpoint del repository di pacchetti del repository downstream. Con una relazione a monte, i contenuti dei due repository di pacchetti vengono effettivamente uniti dal punto di vista di un client.
Ad esempio, se un gestore di pacchetti richiede una versione del pacchetto che non esiste in un repository, CodeCatalyst cercherà la versione del pacchetto negli archivi upstream configurati. La ricerca nei repository upstream viene effettuata nell'ordine in cui sono configurati e, una volta trovato un pacchetto, interromperà la ricerca. CodeCatalyst
## Repository di gateway
Un *repository gateway* è un tipo speciale di repository di pacchetti collegato a un'autorità di gestione dei pacchetti esterna e ufficiale supportata. Quando si aggiunge un repository gateway come repository [upstream, è possibile utilizzare i pacchetti dell'](#packages-concepts-upstream-repositories)autorità di gestione dei pacchetti ufficiale corrispondente. Il repository downstream non comunica con l'archivio pubblico, ma tutto viene intermediato dal repository gateway. I pacchetti utilizzati in questo modo vengono archiviati sia nel repository del gateway che nell'archivio a valle che ha ricevuto la richiesta originale.
I repository gateway sono predefiniti, ma devono essere creati in ogni progetto da utilizzare. L'elenco seguente contiene tutti i repository gateway in cui è possibile creare CodeCatalyst e l'autorità del pacchetto a cui sono collegati.
+ **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 da Google Android.
+ **commonsware-gateway** fornisce pacchetti Maven da. CommonsWare
+ **gradle-plugins-gateway**fornisce pacchetti Maven da Gradle Plugins.
+ **nuget-gallery-gateway**fornisce NuGet pacchetti dalla Galleria. NuGet
+ **pypi-gateway fornisce** pacchetti Python dal Python Package Index.
# Configurazione e utilizzo degli archivi di pacchetti
In CodeCatalyst, i pacchetti vengono archiviati e gestiti all'interno di archivi di pacchetti. Per pubblicare CodeCatalyst o utilizzare pacchetti da un CodeCatalyst (o da qualsiasi archivio pubblico di pacchetti supportato), è necessario creare un archivio di pacchetti e collegarvi il gestore di pacchetti.
**Topics**
+ [Creazione di un archivio di pacchetti](packages-repositories-create.md)
+ [Connessione a un repository di pacchetti](packages-repositories-connect.md)
+ [Eliminazione di un archivio di pacchetti](packages-repositories-delete.md)
# Creazione di un archivio di pacchetti
Effettuare le seguenti operazioni per creare un archivio di pacchetti in. CodeCatalyst
**Per creare un archivio di pacchetti**
1. Apri la CodeCatalyst console all'indirizzo [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Passa al progetto in cui desideri creare un archivio di pacchetti.
1. Dal riquadro di navigazione, scegli **Pacchetti**.
1. Nella pagina **Package repository**, scegli **Create package repository**.
1. Nella sezione **Dettagli del repository Package**, aggiungi quanto segue:
1. **Nome del repository.** Prendi in considerazione l'utilizzo di un nome descrittivo con dettagli come il nome del progetto o del team o come verrà utilizzato il repository.
1. **(Facoltativo) Descrizione.** Una descrizione del repository è particolarmente utile quando in un progetto sono presenti più repository in più team.
1. Nella sezione Archivi **upstream, scegli Seleziona repository** **upstream per aggiungere tutti gli archivi** di pacchetti a cui desideri accedere tramite il tuo repository di pacchetti. CodeCatalyst **Puoi aggiungere **repository Gateway per connetterti a repository di pacchetti** esterni o ad altri repository. CodeCatalyst **
1. Quando un pacchetto viene richiesto da un repository di pacchetti, la ricerca nei repository originari verrà effettuata nell'ordine in cui appaiono in questo elenco. Una volta trovato un pacchetto, CodeCatalyst interromperà la ricerca. Per modificare l'ordine dei repository originali, puoi trascinarli nell'elenco.
1. Scegli **Crea per creare** il tuo repository di pacchetti.
# Connessione a un repository di pacchetti
Per pubblicare o utilizzare pacchetti da CodeCatalyst, è necessario configurare il gestore di pacchetti con le informazioni e CodeCatalyst le credenziali dell'endpoint del repository dei pacchetti. Se non hai creato un repository, puoi farlo seguendo le istruzioni riportate in. [Creazione di un archivio di pacchetti](packages-repositories-create.md)
Per istruzioni su come connettere un gestore di pacchetti a un repository di CodeCatalyst pacchetti, consulta la seguente documentazione.
+ [Configurazione e utilizzo di Gradle Groovy](packages-maven-gradle.md)
+ [Configurazione e utilizzo di mvn](packages-maven-mvn.md)
+ [Configurazione e utilizzo della CLI nuget o dotnet](packages-nuget-cli.md)
+ [Configurazione e utilizzo di npm](packages-npm-use.md)
+ [Configurazione di pip e installazione di pacchetti Python](packages-python-pip.md)
+ [Configurazione di Twine e pubblicazione di pacchetti Python](packages-python-twine.md)
# Eliminazione di un archivio di pacchetti
Effettuare le seguenti operazioni per eliminare un archivio di pacchetti in. CodeCatalyst
**Per eliminare un archivio di pacchetti**
1. Apri la CodeCatalyst console all'indirizzo [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Passa al progetto che contiene l'archivio dei pacchetti che desideri eliminare.
1. Dal riquadro di navigazione, scegli **Pacchetti**.
1. Nella pagina **Package repository**, scegli il repository che desideri eliminare.
1. Scegli **Elimina**.
1. Esamina le informazioni fornite sugli effetti dell'eliminazione di un archivio di pacchetti.
1. **Entra `delete` nel campo di immissione e scegli Elimina.**
# Configurazione e utilizzo degli archivi upstream
Puoi connettere sia i repository gateway che gli altri repository di CodeCatalyst pacchetti, come stream upstream ai tuoi repository di pacchetti. Ciò consente a un client di gestione dei pacchetti di accedere ai pacchetti contenuti in più di un archivio di pacchetti utilizzando un singolo endpoint di repository di pacchetti. Di seguito sono riportati i principali vantaggi dell'utilizzo degli archivi upstream:
+ Devi solo configurare il tuo gestore di pacchetti con un singolo endpoint di repository da estrarre da più fonti.
+ I pacchetti utilizzati da un repository upstream vengono archiviati nel repository downstream, il che garantisce la disponibilità dei pacchetti anche in caso di interruzioni impreviste del repository upstream o se i pacchetti nell'archivio upstream vengono eliminati.
È possibile aggiungere repository upstream quando si crea un archivio di pacchetti. È inoltre possibile aggiungere o rimuovere repository upstream dagli archivi di pacchetti esistenti nella console. CodeCatalyst
Quando si aggiunge un repository gateway come repository upstream, l'archivio dei pacchetti viene collegato al corrispondente repository pubblico di pacchetti del repository gateway. Per un elenco degli archivi pubblici di pacchetti supportati, vedere. [Archivi di pacchetti esterni supportati e relativi repository gateway](packages-connect-external.md#packages-upstream-repositories-supported-external)
È possibile collegare più repository tra loro come repository upstream. Ad esempio, supponiamo che il tuo team crei un repository denominato `project-repo` e stia già utilizzando un altro repository denominato a cui è stato **npm-public-registry-gateway**aggiunto come repository upstream, `team-repo` che è collegato al repository pubblico npm,. `npmjs.com` Puoi aggiungere come repository upstream a. `team-repo` `project-repo` In questo caso, devi solo configurare il tuo gestore di pacchetti da utilizzare per `project-repo` estrarre i pacchetti da`project-repo`, `team-repo``npm-public-registry-gateway`, e. `npmjs.com`
**Topics**
+ [Aggiunta di un repository upstream](packages-upstream-repositories-add.md)
+ [Modifica dell'ordine di ricerca dei repository upstream](packages-upstream-repositories-search-order.md)
+ [Richiesta di una versione del pacchetto con repository upstream](packages-upstream-repositories-request.md)
+ [Rimozione di un repository upstream](packages-upstream-repositories-remove.md)
# Aggiunta di un repository upstream
L'aggiunta di un archivio pubblico di CodeCatalyst pacchetti o un altro archivio di pacchetti come repository upstream al repository downstream rende tutti i pacchetti nell'archivio upstream disponibili ai gestori di pacchetti collegati al repository downstream.
**Per aggiungere un repository upstream**
1. Nel riquadro di navigazione scegliere **Pacchetti**.
1. Nella pagina **Package repository**, scegli il repository di pacchetti a cui desideri aggiungere un repository upstream.
1. **Sotto il nome del repository dei pacchetti, scegli **Upstreams e scegli Seleziona repository upstream**.**
1. In **Seleziona il tipo di upstream**, scegli una delle seguenti opzioni:
+ **Archivi Gateway**
È possibile scegliere da un elenco di repository gateway disponibili.
**Nota**
Per connettersi alle autorità pubbliche di gestione dei pacchetti esterne come Maven Central, npmjs.com o Nuget Gallery, CodeCatalyst utilizza gli archivi gateway come repository intermedi che cercano e archiviano i pacchetti estratti da repository esterni. Ciò consente di risparmiare tempo e trasferimento di dati poiché tutti gli archivi di pacchetti di un progetto utilizzeranno i pacchetti del repository intermediario del gateway. Per ulteriori informazioni, consulta [Connessione a repository esterni pubblici](packages-connect-external.md).
+ **CodeCatalyst archivi**
Puoi scegliere da un elenco di repository di CodeCatalyst pacchetti disponibili nel tuo progetto.
1. **Dopo aver selezionato tutti i repository che desideri aggiungere come repository upstream, scegli **Seleziona, quindi** scegli Salva.**
Per ulteriori informazioni sulla modifica dell'ordine di ricerca dei repository upstream, consulta. [Modifica dell'ordine di ricerca dei repository upstream](packages-upstream-repositories-search-order.md)
Dopo aver aggiunto un repository upstream, puoi utilizzare un gestore di pacchetti collegato al tuo repository locale per recuperare i pacchetti dal repository upstream. Non è necessario aggiornare la configurazione del gestore di pacchetti. Per ulteriori informazioni sulla richiesta delle versioni dei pacchetti da un repository upstream, consulta. [Richiesta di una versione del pacchetto con repository upstream](packages-upstream-repositories-request.md)
# Modifica dell'ordine di ricerca dei repository upstream
CodeCatalyst cerca negli archivi upstream nell'ordine di ricerca configurato. Quando viene trovato un pacchetto, CodeCatalyst interrompe la ricerca. È possibile modificare l'ordine in cui vengono cercati i pacchetti nei repository originali.
**Per modificare l'ordine di ricerca dei repository upstream**
1. Nel riquadro di navigazione scegliere **Pacchetti**.
1. Nella pagina **Package repository**, scegli l'archivio dei pacchetti di cui desideri modificare l'ordine di ricerca del repository upstream.
1. **Sotto il nome del repository dei pacchetti, scegli Upstreams.**
1. Nella sezione Archivi **upstream, puoi visualizzare i repository** upstream e il loro ordine di ricerca. Per modificare l'ordine di ricerca, trascina i repository nell'elenco.
1. **Quando hai finito di modificare l'ordine di ricerca dei repository originali, scegli Salva.**
# Richiesta di una versione del pacchetto con repository upstream
L'esempio seguente mostra i possibili scenari in cui un gestore di pacchetti richiede un pacchetto da un CodeCatalyst repository di pacchetti che dispone di repository upstream.
Per questo esempio, un gestore di pacchetti, ad esempio`npm`, richiede una versione del pacchetto da un archivio di pacchetti denominato `downstream` che ha più repository upstream. Quando viene richiesto il pacchetto, può verificarsi quanto segue:
+ Se `downstream` contiene la versione del pacchetto richiesta, viene restituita al client.
+ Se `downstream` non contiene la versione del pacchetto richiesta, la CodeCatalyst cerca nei `downstream` repository upstream, nell'ordine di ricerca configurato. Se viene trovata la versione del pacchetto, viene copiato un riferimento ad essa e la versione del pacchetto viene restituita al `downstream` client.
+ Se nessuno dei `downstream` suoi repository upstream contiene la versione del pacchetto, al client viene restituita una `Not Found` risposta HTTP 404.
Il numero massimo di repository diretti upstream consentito per un repository è 10. Il numero massimo di CodeCatalyst ricerche nei repository quando viene richiesta una versione del pacchetto è 25.
## Package retention dai repository upstream
Se una versione del pacchetto richiesta viene trovata in un repository upstream, viene mantenuto un riferimento ad essa ed è sempre disponibile nell'archivio che l'ha richiesta. Ciò garantisce l'accesso ai pacchetti in caso di interruzione imprevista dell'archivio upstream. La versione del pacchetto mantenuta non è influenzata da nessuno dei seguenti fattori:
+ Eliminazione del repository upstream.
+ Disconnessione del repository upstream dal repository downstream.
+ Eliminazione della versione del pacchetto dal repository upstream.
+ Modifica della versione del pacchetto nell'archivio upstream (ad esempio, aggiungendovi una nuova risorsa).
## Recupero dei pacchetti tramite una relazione a monte
CodeCatalyst può recuperare pacchetti tramite più repository collegati chiamati repository upstream. Se un repository di CodeCatalyst pacchetti ha una connessione upstream a un altro repository di CodeCatalyst pacchetti che ha una connessione upstream a un repository gateway, le richieste di pacchetti non presenti nell'archivio upstream vengono copiate dal repository esterno. Ad esempio, considerate la seguente configurazione: un repository denominato `repo-A` ha una connessione upstream al repository del gateway,. `npm-public-registry-gateway` `npm-public-registry-gateway`ha una connessione upstream al repository pubblico dei pacchetti,. [https://npmjs.com](https://npmjs.com)
![\[Semplice diagramma del repository upstream che mostra tre repository concatenati tra loro.\]](http://docs.aws.amazon.com/it_it/codecatalyst/latest/userguide/images/packages/upstream-with-external.png)
Se `npm` è configurato per utilizzare il `repo-A` repository, l'esecuzione `npm install` avvia la copia dei pacchetti da dentro. [https://npmjs.com](https://npmjs.com)`npm-public-registry-gateway` Vengono inoltre inserite le versioni installate. `repo-A` L'esempio seguente installa`lodash`.
```
$ npm config get registry
https://packages.region.codecatalyst.aws/npm/space-name/proj-name/repo-name/
$ npm install lodash
+ lodash@4.17.20
added 1 package from 2 contributors in 6.933s
```
Dopo l'esecuzione`npm install`, `repo-A` contiene solo la versione più recente (`lodash 4.17.20`) perché è la versione che è stata recuperata da`npm`. `repo-A`
Perché `npm-public-registry-gateway` dispone di una connessione upstream esterna a [https://npmjs.com](https://npmjs.com), tutte le versioni del pacchetto da cui vengono importate [https://npmjs.com](https://npmjs.com)vengono archiviate in. `npm-public-registry-gateway` Queste versioni del pacchetto avrebbero potuto essere recuperate da qualsiasi repository downstream con una connessione upstream che porta a. `npm-public-registry-gateway`
Il contenuto di `npm-public-registry-gateway` fornisce un modo per visualizzare tutti i pacchetti e le versioni dei pacchetti importati nel tempo. [https://npmjs.com](https://npmjs.com)
## Conservazione dei pacchetti in repository intermedi
CodeCatalyst consente di concatenare repository upstream. Ad esempio, `repo-A` può avere `repo-B` come repository upstream e `repo-B` può avere `repo-C` come repository upstream. Questa configurazione rende le versioni del pacchetto in `repo-B` e disponibili da. `repo-C` `repo-A`
![\[Semplice diagramma del repository upstream che mostra tre repository concatenati tra loro.\]](http://docs.aws.amazon.com/it_it/codecatalyst/latest/userguide/images/packages/upstream-chaining.png)
Quando un gestore di pacchetti si connette al repository `repo-A` e recupera una versione del pacchetto dal repository`repo-C`, la versione del pacchetto non viene conservata nell'archivio. `repo-B` La versione del pacchetto viene conservata solo nell'archivio a valle più lontano, che in questo esempio è. `repo-A` Non viene conservata in nessun archivio intermedio. Questo vale anche per le catene più lunghe; ad esempio, se ci fossero quattro repository:`repo-A`,, e `repo-B` `repo-C``repo-D`, e un gestore di pacchetti collegato al quale è stata `repo-A` recuperata una versione del pacchetto`repo-D`, la versione del pacchetto verrebbe conservata in ma non in o. `repo-A` `repo-B` `repo-C`
Il comportamento di conservazione dei pacchetti è simile quando si estrae una versione del pacchetto da un archivio pubblico di pacchetti, tranne per il fatto che la versione del pacchetto viene sempre conservata nell'archivio del gateway che ha la connessione diretta a monte all'archivio pubblico. Ad esempio, ha come repository upstream`repo-A`. `repo-B` `repo-B`ha `npm-public-registry-gateway` come repository upstream, che ha una connessione upstream al repository pubblico, **npmjs.com**; vedi lo schema seguente.
![\[Diagramma del repository upstream che mostra tre repository concatenati tra loro con una connessione upstream esterna a npmjs.com.\]](http://docs.aws.amazon.com/it_it/codecatalyst/latest/userguide/images/packages/upstream-chaining-external.png)
**Se un gestore di pacchetti connesso `repo-A` richiede una versione specifica del pacchetto, ad esempio *lodash 4.17.20*, e la versione del pacchetto non è presente in nessuno dei tre repository, verrà recuperata da npmjs.com.** **Quando *lodash 4.17.20* viene recuperato, viene mantenuto in `repo-A` quanto si tratta del repository a valle più lontano e poiché dispone della connessione a monte al repository esterno pubblico, npmjs.com. `npm-public-registry-gateway`** *lodash* 4.17.20 `repo-B` non viene mantenuto perché si tratta di un repository intermedio.
# Rimozione di un repository upstream
Se non desideri più accedere ai pacchetti all'interno di un repository upstream, puoi rimuovere il repository upstream da un repository di pacchetti.
**avvertimento**
Quando rimuovi un repository upstream, potresti interrompere le catene di relazioni originarie, il che potrebbe interrompere i tuoi progetti o le tue build.
**Per rimuovere un repository upstream**
1. Nel riquadro di navigazione scegliere **Pacchetti**.
1. Nella pagina **Package repository**, scegli il repository di pacchetti da cui desideri rimuovere un repository upstream.
1. **Sotto il nome del repository dei pacchetti, scegli Upstreams.**
1. Nella sezione **Modifica repository upstream, trova il repository** upstream che desideri rimuovere e scegli. ![\[Remove\]](http://docs.aws.amazon.com/it_it/codecatalyst/latest/userguide/images/packages/remove.png)
1. **Quando hai finito di rimuovere i repository upstream, scegli Salva.**
# Connessione a repository esterni pubblici
È possibile connettere gli archivi dei CodeCatalyst pacchetti ai repository esterni pubblici supportati aggiungendo il repository gateway corrispondente come repository upstream. I repository gateway fungono da repository intermedi che cercano e archiviano i pacchetti estratti da repository esterni. Ciò consente di risparmiare tempo e trasferimento di dati perché tutti gli archivi di pacchetti di un progetto possono utilizzare i pacchetti archiviati dal repository del gateway.
**Per connettersi a un archivio pubblico utilizzando i repository gateway**
1. Nel riquadro di navigazione scegliere **Pacchetti**.
1. In **Pacchetti**, scegli la pagina dei **repository Gateway**. È possibile visualizzare un elenco di repository gateway supportati e le relative descrizioni.
1. Per utilizzare un repository gateway, è necessario innanzitutto crearlo. Se il repository gateway è stato creato, vengono visualizzate la data e l'ora di creazione. In caso contrario, scegli **Crea** per crearlo.
1. Per utilizzare i pacchetti del repository del gateway, è necessario impostare una connessione upstream ad esso da un CodeCatalyst repository. Scegli **Package repository** e scegli il repository di pacchetti a cui vuoi connetterti.
1. **Per connetterti al repository pubblico, scegli **Upstreams e seleziona Seleziona repository upstream**.**
1. Scegliete **Gateway repository**, selezionate il repository gateway che corrisponde al repository pubblico a cui desiderate connettervi come repository upstream.
1. **Dopo aver selezionato tutti i repository gateway che desideri aggiungere come repository upstream, scegli Seleziona.**
1. **Quando hai finito di ordinare i repository upstream, scegli Salva.**
Per ulteriori informazioni sui repository upstream, consulta. [Configurazione e utilizzo degli archivi upstream](packages-upstream-repositories.md)
Dopo aver aggiunto un repository gateway come repository upstream, puoi utilizzare un gestore di pacchetti collegato al tuo repository locale per recuperare i pacchetti dall'archivio di pacchetti pubblico ed esterno che gli corrisponde. Non è necessario aggiornare la configurazione del gestore dei pacchetti. I pacchetti utilizzati in questo modo vengono archiviati sia nel repository del gateway che nell'archivio dei pacchetti locale. Per ulteriori informazioni sulla richiesta delle versioni dei pacchetti da un repository upstream, consulta. [Richiesta di una versione del pacchetto con repository upstream](packages-upstream-repositories-request.md)
## Archivi di pacchetti esterni supportati e relativi repository gateway
CodeCatalyst supporta l'aggiunta di una connessione upstream alle seguenti autorità ufficiali di gestione dei pacchetti con repository gateway.
| Tipo di pacchetto del repository | Description | Nome del repository del gateway |
| --- | --- | --- |
| npm | registro pubblico npm | npm-public-registry-gateway |
| Python | Indice dei pacchetti Python | pypi-gateway |
| Maven | Maven Central | maven-central-gateway |
| Maven | Archivio Google Android | google-android-gateway |
| Maven | CommonsWare | commonsware-gateway |
| Maven | Archivio di plugin Gradle | gradle-plugins-gateway |
| NuGet | NuGet Galleria | nuget-gallery-gateway |
# Pubblicazione e modifica di pacchetti
Un *pacchetto* in CodeCatalyst è un insieme di software e metadati necessari per risolvere le dipendenze e installare il software. Per un elenco dei formati di pacchetto supportati in CodeCatalyst, vedere. [Pubblica e condividi pacchetti software in CodeCatalyst](packages.md) Questa sezione fornisce informazioni sulla pubblicazione, la visualizzazione, l'eliminazione dei pacchetti e l'aggiornamento dello stato di una versione del pacchetto.
**Topics**
+ [Pubblicazione di pacchetti in un archivio di CodeCatalyst pacchetti](package-publishing.md)
+ [Visualizzazione dei dettagli della versione del pacchetto](working-with-packages-view.md)
+ [Eliminazione di una versione del pacchetto](working-with-packages-delete.md)
+ [Aggiornamento dello stato di una versione del pacchetto](working-with-packages-update-version-status.md)
+ [Modifica dei controlli di origine dei pacchetti](package-origin-controls.md)
# Pubblicazione di pacchetti in un archivio di CodeCatalyst pacchetti
È possibile pubblicare versioni di qualsiasi tipo di pacchetto supportato in un archivio di CodeCatalyst pacchetti utilizzando gli strumenti di gestione dei pacchetti. I passaggi per pubblicare una versione del pacchetto sono i seguenti:
**Per pubblicare una versione del pacchetto in un archivio di CodeCatalyst pacchetti**
1. In caso contrario, [crea un archivio di pacchetti](packages-repositories-create.md).
1. Connect il gestore di pacchetti al repository dei pacchetti. Per istruzioni su come connettere il gestore di pacchetti npm a un repository di CodeCatalyst pacchetti, vedi. [Configurazione e utilizzo di npm](packages-npm-use.md)
1. Usa il tuo gestore di pacchetti connesso per pubblicare le versioni dei pacchetti.
**Contents**
+ [Pubblicazione e repository upstream](#package-publishing-upstreams)
+ [Pacchetti privati e archivi pubblici](#package-publishing-upstreams-direct)
+ [Sovrascrivere le risorse del](#package-publishing-overwrite-assets)
## Pubblicazione e repository upstream
In CodeCatalyst, non è possibile pubblicare versioni di pacchetti presenti in repository upstream raggiungibili o in repository pubblici. Ad esempio, supponiamo di voler pubblicare un pacchetto npm in un repository di pacchetti e di essere connesso a npmjs.com tramite un repository `myrepo` gateway configurato come repository upstream. `lodash@1.0` `myrepo` Se `lodash@1.0` è presente nel repository upstream o in npmjs.com, rifiuta qualsiasi tentativo di pubblicazione su di esso emettendo un errore di conflitto 409. CodeCatalyst `myrepo` Ciò consente di evitare la pubblicazione accidentale di un pacchetto con lo stesso nome e la stessa versione di un pacchetto in un repository upstream, il che può causare un comportamento imprevisto.
È comunque possibile pubblicare versioni diverse del nome di pacchetto che esistono in un repository upstream. Ad esempio, se `lodash@1.0` è presente in un repository upstream ma non lo è, `lodash@1.1` è possibile pubblicarlo `lodash@1.1` nel repository downstream.
## Pacchetti privati e archivi pubblici
CodeCatalyst non pubblica i pacchetti archiviati negli CodeCatalyst archivi in archivi pubblici, come npmjs.com o Maven Central. CodeCatalyst importa pacchetti da repository pubblici in un CodeCatalyst repository, ma non sposta i pacchetti nella direzione opposta. I pacchetti pubblicati CodeCatalyst nei repository rimangono privati e sono disponibili solo per il CodeCatalyst progetto a cui appartiene il repository.
## Sovrascrivere le risorse del
Non è possibile ripubblicare una risorsa del pacchetto già esistente con contenuti diversi. Ad esempio, supponete di aver già pubblicato un pacchetto Maven con una risorsa JAR. `mypackage-1.0.jar` Puoi pubblicare nuovamente quella risorsa solo se il checksum delle risorse vecchie e nuove è identico. Per ripubblicare la stessa risorsa con nuovi contenuti, eliminate prima la versione del pacchetto. Il tentativo di ripubblicare lo stesso nome di risorsa con contenuti diversi genererà un errore di conflitto HTTP 409.
Per i formati di pacchetto che supportano più risorse (Python e Maven), puoi aggiungere nuove risorse con nomi diversi a una versione del pacchetto esistente in qualsiasi momento, supponendo che tu disponga delle autorizzazioni richieste. Poiché npm supporta NuGet solo una singola risorsa per versione del pacchetto, per modificare una versione del pacchetto pubblicata devi prima eliminarla.
Se provate a ripubblicare una risorsa già esistente (ad esempio`mypackage-1.0.jar`) e il contenuto della risorsa pubblicata e della nuova risorsa sono identici, l'operazione avrà successo perché l'operazione è idempotente.
# Visualizzazione dei dettagli della versione del pacchetto
È possibile utilizzare la CodeCatalyst console per visualizzare i dettagli su una versione specifica del pacchetto.
**Per visualizzare i dettagli della versione del pacchetto**
1. Nel riquadro di navigazione scegliere **Pacchetti**.
1. Nella pagina **Package repository**, scegli il repository che contiene la versione del pacchetto di cui desideri visualizzare i dettagli.
1. Cerca la versione del pacchetto nella tabella **Pacchetti**. È possibile utilizzare la barra di ricerca per filtrare i pacchetti in base al nome e al formato del pacchetto. Scegli il pacchetto dall'elenco.
1. Nella pagina dei **dettagli del pacchetto**, scegli **Versioni**, quindi scegli la versione che desideri visualizzare.
# Eliminazione di una versione del pacchetto
È possibile eliminare una versione del pacchetto dalla pagina dei **dettagli della versione del pacchetto** nella CodeCatalyst console.
**Per eliminare una versione del pacchetto**
1. Nel riquadro di navigazione scegliere **Pacchetti**.
1. Nella pagina **Package repository**, scegli il repository che contiene la versione del pacchetto che desideri eliminare.
1. Cerca e scegli il pacchetto dalla tabella.
1. Nella pagina dei **dettagli del pacchetto**, scegli **Versioni** e scegli la versione che desideri eliminare.
1. Nella pagina dei **dettagli della versione del Package**, scegli **Azioni versione**, quindi scegli **Elimina**.
1. Inserisci *delete* nel campo di testo e scegli **Elimina**.
# Aggiornamento dello stato di una versione del pacchetto
Ogni versione del pacchetto in CodeCatalyst ha uno stato che descrive lo stato attuale e la disponibilità della versione del pacchetto. È possibile modificare lo stato della versione del pacchetto nella CodeCatalyst console. Per ulteriori informazioni sui possibili valori di stato delle versioni dei pacchetti e sui relativi significati, vedere[Stato della versione del pacchetto](#package-version-status).
**Per aggiornare lo stato di una versione del pacchetto**
1. Nel riquadro di navigazione scegliere **Pacchetti**.
1. Nella pagina **Package repository**, scegli il repository che contiene la versione del pacchetto di cui vuoi aggiornare lo stato.
1. Cerca e scegli il pacchetto dalla tabella.
1. Nella pagina dei **dettagli del pacchetto**, scegli **Versioni**, quindi scegli la versione che desideri visualizzare.
1. Nella pagina dei **dettagli della versione del Package**, scegli **Azioni**, quindi scegli **Rimuovi dalla lista**, **Archivia** o **Elimina**. Per informazioni sullo stato di ogni versione del pacchetto, consulta. [Stato della versione del pacchetto](#package-version-status)
1. Inserisci il testo di conferma nel campo di testo, quindi scegli Rimuovi **dalla lista**, **Archivia** o **Elimina**, a seconda dello stato a cui stai effettuando l'aggiornamento.
## Stato della versione del pacchetto
Di seguito sono riportati i valori possibili per lo stato della versione del pacchetto. È possibile modificare lo stato della versione del pacchetto nella console. Per ulteriori informazioni, consulta [Aggiornamento dello stato di una versione del pacchetto](#working-with-packages-update-version-status).
+ **Pubblicato**: la versione del pacchetto è stata pubblicata correttamente e può essere richiesta da un gestore di pacchetti. La versione del pacchetto verrà inclusa negli elenchi delle versioni dei pacchetti restituiti ai gestori di pacchetti; ad esempio, nell'output di`npm view versions`. Tutte le risorse della versione del pacchetto sono disponibili nel repository.
+ **Non completato**: l’ultimo tentativo di pubblicazione non è stato completato. **Attualmente solo le versioni dei pacchetti Maven possono avere lo stato Incompiuto.** Ciò può verificarsi quando il client carica una o più risorse per una versione del pacchetto ma non pubblica un `maven-metadata.xml` file per il pacchetto che include quella versione.
+ **Non in elenco**: gli asset della versione del pacchetto possono essere scaricati dal repository, ma la versione del pacchetto non è inclusa nell'elenco delle versioni restituite ai gestori di pacchetti. Ad esempio, per un pacchetto npm, l'output di `npm view versions` non include la versione del pacchetto. Ciò significa che la logica di risoluzione delle dipendenze di npm non seleziona la versione del pacchetto perché la versione non compare nell'elenco delle versioni disponibili. Tuttavia, se la versione del pacchetto **Unlisted** è già referenziata in un `npm package-lock.json` file, può comunque essere scaricata e installata; ad esempio, durante l'esecuzione. `npm ci`
+ **Archiviato: gli** asset della versione del pacchetto non possono essere scaricati. La versione del pacchetto non verrà inclusa nell'elenco delle versioni restituite ai gestori di pacchetti. Poiché gli asset non sono disponibili, il consumo della versione del pacchetto da parte dei client è bloccato. Se la compilazione dell'applicazione dipende da una versione aggiornata a **Archived**, la compilazione avrà esito negativo, a meno che la versione del pacchetto non sia stata memorizzata nella cache locale. Non puoi utilizzare un gestore di pacchetti o uno strumento di compilazione per ripubblicare una versione del pacchetto **archiviato** perché è ancora presente nel repository. Tuttavia, puoi modificare lo stato della versione del pacchetto riportandolo a **Non in elenco** o **Pubblicato** nella console.
+ **Eliminata**: la versione del pacchetto non viene visualizzata negli elenchi e le risorse non possono essere scaricate dal repository. La differenza fondamentale tra **Disposed** e **Archived** è che con lo stato **Disposed**, le risorse della versione del pacchetto vengono eliminate definitivamente da. CodeCatalyst ****Per questo motivo, non è possibile spostare una versione del pacchetto da **Disposed** a **Archiviata, Non elencata** o Pubblicata.**** La versione del pacchetto non può essere utilizzata perché le risorse sono state eliminate. Quando una versione del pacchetto è contrassegnata come **Disposta**, non vi viene addebitata alcuna fattura per l'archiviazione delle risorse del pacchetto.
Oltre agli stati nell'elenco precedente, è possibile eliminare anche una versione del pacchetto. Una volta eliminata, la versione del pacchetto non è più presente nell'archivio ed è possibile ripubblicare liberamente quella versione del pacchetto utilizzando un gestore di pacchetti o uno strumento di compilazione.
## Nome del pacchetto, versione del pacchetto e normalizzazione del nome dell'asset
CodeCatalyst normalizza i nomi dei pacchetti, le versioni dei pacchetti e i nomi delle risorse prima di archiviarli, il che significa che i nomi o le versioni CodeCatalyst possono essere diversi dal nome o dalla versione forniti al momento della pubblicazione del pacchetto. Per ulteriori informazioni su come vengono normalizzati i nomi e le versioni CodeCatalyst per ogni tipo di pacchetto, consultate la seguente documentazione.
+ [Normalizzazione dei nomi dei pacchetti in Python](python-name-normalization.md)
+ [NuGet normalizzazione del nome del pacchetto, della versione e del nome dell'asset](nuget-name-normalization.md)
CodeCatalyst non esegue la normalizzazione su altri formati di pacchetti.
# Modifica dei controlli di origine dei pacchetti
In Amazon CodeCatalyst, le versioni dei pacchetti possono essere aggiunte a un archivio di pacchetti pubblicandole direttamente, estraendole da un repository upstream o importandole da un archivio pubblico esterno tramite un gateway. Se consenti l'aggiunta di versioni di un pacchetto sia tramite pubblicazione diretta che tramite acquisizione da archivi pubblici, sei vulnerabile a un attacco di sostituzione delle dipendenze. Per ulteriori informazioni, consulta [Attacchi di sostituzione delle dipendenze](#dependency-substitution-attacks). Per proteggerti da un attacco di sostituzione delle dipendenze, configura i controlli di origine dei pacchetti su un pacchetto in un repository per limitare il modo in cui le versioni di quel pacchetto possono essere aggiunte al repository.
Dovresti prendere in considerazione la possibilità di configurare i controlli di origine dei pacchetti per fare in modo che le nuove versioni di pacchetti diversi provengano sia da fonti interne, come la pubblicazione diretta, sia da fonti esterne, come gli archivi pubblici. Per impostazione predefinita, i controlli di origine dei pacchetti sono configurati in base al modo in cui la prima versione di un pacchetto viene aggiunta all'archivio.
## Impostazioni di controllo dell'origine del pacchetto
Con i controlli sull'origine dei pacchetti, è possibile configurare il modo in cui le versioni dei pacchetti possono essere aggiunte a un repository. Gli elenchi seguenti includono le impostazioni e i valori disponibili per il controllo dell'origine dei pacchetti.
**Pubblicare**
Questa impostazione configura se le versioni dei pacchetti possono essere pubblicate direttamente nel repository utilizzando gestori di pacchetti o strumenti simili.
+ **ALLOW**: le versioni dei Package possono essere pubblicate direttamente.
+ **BLOCK**: Le versioni dei pacchetti non possono essere pubblicate direttamente.
**A monte**
Questa impostazione configura se le versioni dei pacchetti possono essere importate da archivi pubblici esterni o conservate dagli archivi upstream quando richiesto da un gestore di pacchetti.
+ **CONSENTI**: qualsiasi versione del pacchetto può essere conservata da altri CodeCatalyst repository configurati come archivi upstream o importata da una fonte pubblica con una connessione esterna.
+ **BLOCK**: le versioni dei pacchetti non possono essere conservate da altri CodeCatalyst repository configurati come repository upstream o importate da una fonte pubblica con una connessione esterna.
### Impostazioni predefinite per il controllo dell'origine dei pacchetti
I controlli di origine del pacchetto predefiniti per un pacchetto si baseranno su come la prima versione di quel pacchetto viene aggiunta all'archivio dei pacchetti.
+ Se la prima versione del pacchetto viene pubblicata direttamente da un gestore di pacchetti, le impostazioni saranno **Publish: ALLOW e **Upstream**: BLOCK**.
+ **Se la prima versione del pacchetto viene importata da una fonte pubblica, le impostazioni saranno **Publish: BLOCK e Upstream:** ALLOW.**
## Scenari comuni di controllo dell'accesso ai pacchetti
Questa sezione descrive alcuni scenari comuni di aggiunta di una versione del pacchetto a un repository di CodeCatalyst pacchetti. Le impostazioni di controllo dell'origine dei pacchetti vengono impostate per i nuovi pacchetti a seconda di come viene aggiunta la prima versione del pacchetto.
Nei seguenti scenari, un *pacchetto interno* viene pubblicato direttamente da un gestore di pacchetti nel repository, ad esempio un pacchetto gestito dall'utente. Un *pacchetto esterno* è un pacchetto esistente in un archivio pubblico che può essere inserito nel repository dell'utente tramite un repository gateway upstream.
**Viene pubblicata una versione esterna del pacchetto per un pacchetto interno esistente**
In questo scenario, si consideri un pacchetto interno, *PackageA*. Il tuo team pubblica la prima versione del pacchetto per *PackageA in un archivio di pacchetti.* CodeCatalyst **Poiché questa è la prima versione del pacchetto, le impostazioni di controllo dell'origine del pacchetto vengono impostate automaticamente su **Pubblica: Consenti e Upstream:** Block.** Dopo la pubblicazione del pacchetto nel repository, un pacchetto con lo stesso nome viene pubblicato in un archivio pubblico collegato all'archivio dei pacchetti. CodeCatalyst Potrebbe trattarsi di un tentativo di attacco di sostituzione delle dipendenze contro il pacchetto interno o potrebbe essere una coincidenza. In ogni caso, i controlli di origine dei pacchetti sono configurati per bloccare l'ingestione della nuova versione esterna per proteggersi da un potenziale attacco.
Nell'immagine seguente, *RePoA è il tuo repository di CodeCatalyst pacchetti con una* connessione upstream al repository. `npm-public-registry-gateway` Il tuo repository contiene le versioni 1.1 e 2.1 di *PackageA, ma la versione 3.0* è pubblicata nell'archivio pubblico. Normalmente, *RePoA inserisce* la versione 3.0 dopo che il pacchetto è stato richiesto da un gestore di pacchetti. Poiché l'ingestione dei pacchetti è impostata su **Block**, la versione 3.0 non viene inserita nell'archivio dei pacchetti e non è disponibile per i gestori di CodeCatalyst pacchetti ad esso collegati.
![\[Grafica semplice che mostra una nuova versione esterna del pacchetto bloccata da un archivio pubblico.\]](http://docs.aws.amazon.com/it_it/codecatalyst/latest/userguide/images/packages/package-origin-controls-one.png)
**Viene pubblicata una versione interna del pacchetto per un pacchetto esterno esistente**
In questo scenario, un pacchetto, *PackageB*, esiste esternamente in un repository pubblico collegato al repository. Quando un gestore di pacchetti connesso al tuo repository richiede *PackageB, la versione del pacchetto* viene inserita nel tuo repository dal repository pubblico. ****Poiché questa è la prima versione del pacchetto di *PackageB* aggiunta al repository, le impostazioni di origine del pacchetto sono configurate su Publish: BLOCK e Upstream: ALLOW.**** Successivamente, si tenta di pubblicare una versione con lo stesso nome di pacchetto nel repository. È possibile che non siate a conoscenza del pacchetto pubblico e stiate cercando di pubblicare un pacchetto non correlato con lo stesso nome, oppure state tentando di pubblicare una versione con patch o forse state tentando di pubblicare direttamente la versione esatta del pacchetto che già esiste esternamente. CodeCatalyst rifiuta la versione che state tentando di pubblicare, ma potete ignorare esplicitamente il rifiuto e pubblicare la versione, se necessario.
Nell'immagine seguente, *RePoA è il tuo repository di CodeCatalyst pacchetti con una* connessione upstream al repository. `npm-public-registry-gateway` L'archivio dei pacchetti contiene la versione 3.0 che ha acquisito dal repository pubblico. Vuoi pubblicare la versione 1.2 nel tuo repository di pacchetti. In genere, è possibile pubblicare la versione 1.2 su *RePoA*, ma poiché la pubblicazione è impostata su **Block**, la versione 1.2 non può essere pubblicata.
![\[Grafica semplice che mostra la pubblicazione dei pacchetti bloccata.\]](http://docs.aws.amazon.com/it_it/codecatalyst/latest/userguide/images/packages/package-origin-controls-two.png)
**Pubblicazione di una versione patchata di un pacchetto esterno esistente**
In questo scenario, un pacchetto, *PackageB*, esiste esternamente in un archivio pubblico collegato all'archivio dei pacchetti. Quando un gestore di pacchetti collegato al tuo repository richiede *PackageB, la versione del pacchetto* viene inserita nel tuo repository dal repository pubblico. ****Poiché questa è la prima versione del pacchetto di *PackageB* aggiunta al repository, le impostazioni di origine del pacchetto sono configurate su Publish: BLOCK e Upstream: ALLOW.**** Il tuo team decide di pubblicare le versioni del pacchetto con patch di questo pacchetto nel repository. Per poter pubblicare direttamente le versioni dei pacchetti, il team modifica le impostazioni di controllo dell'origine del pacchetto in **Publish: ALLOW e **Upstream**:** BLOCK. Le versioni di questo pacchetto possono ora essere pubblicate direttamente nel repository e importate da archivi pubblici. **Dopo che il team ha pubblicato le versioni del pacchetto con patch, ripristina le impostazioni di origine del pacchetto su **Publish**: BLOCK e Upstream: ALLOW.**
## Modifica dei controlli di origine dei pacchetti
I controlli di origine dei pacchetti vengono configurati automaticamente in base al modo in cui la prima versione di un pacchetto viene aggiunta all'archivio dei pacchetti. Per ulteriori informazioni, consulta [Impostazioni predefinite per il controllo dell'origine dei pacchetti](#default-package-origin-control-settings). Per aggiungere o modificare i controlli di origine dei pacchetti per un pacchetto in un archivio dei CodeCatalyst pacchetti, effettuate i passaggi indicati nella procedura seguente.
**Per aggiungere o modificare i controlli di origine del pacchetto**
1. Nel riquadro di navigazione scegliere **Pacchetti**.
1. Scegliete l'archivio del pacchetto che contiene il pacchetto che desiderate modificare.
1. Nella tabella **Pacchetti**, cercate e scegliete il pacchetto che desiderate modificare.
1. Dalla pagina di riepilogo del pacchetto, scegli **Origin controls**.
1. In **Origin controls**, scegli i controlli di origine del pacchetto che desideri impostare per questo pacchetto. Entrambe le impostazioni di controllo dell'origine del pacchetto, **Publish** e **Upstream**, devono essere impostate contemporaneamente.
+ Per consentire la pubblicazione diretta delle versioni dei pacchetti, in **Pubblica**, scegli **Consenti**. Per bloccare la pubblicazione delle versioni dei pacchetti, scegli **Blocca**.
+ ****Per consentire l'inserimento di pacchetti da repository esterni e l'estrazione di pacchetti da repository upstream, in Origini upstream, scegli Consenti.**** **Per bloccare tutte le importazioni e l'estrazione di versioni di pacchetti da repository esterni e upstream, scegliete Blocca.**
1. Scegli **Save** (Salva).
## Archiviazione e archivi upstream
In CodeCatalyst, non è possibile pubblicare versioni di pacchetti presenti in repository upstream raggiungibili o in repository pubblici. Ad esempio, supponiamo di voler pubblicare un pacchetto npm in un repository e `myrepo` di disporre di un repository upstream con una `myrepo` connessione esterna `lodash@1.0` a npmjs.com. Considerate i seguenti scenari.
1. Le impostazioni di controllo dell'origine del pacchetto `lodash` sono **Publish: ALLOW** e **Upstream: ALLOW**. Se `lodash@1.0` è presente nel repository upstream o in npmjs.com, CodeCatalyst rifiuta qualsiasi tentativo di pubblicazione su di esso generando un errore di conflitto 409. `myrepo` È comunque possibile pubblicare una versione diversa, ad esempio. `lodash@1.1`
1. Le impostazioni di controllo dell'origine del pacchetto `lodash` sono **Publish: ALLOW** e **Upstream: BLOCK**. Puoi pubblicare nel tuo repository qualsiasi versione `lodash` di che non esista già perché le versioni del pacchetto non sono raggiungibili.
1. Le impostazioni di controllo dell'origine del pacchetto `lodash` sono **Publish: BLOCK** e **Upstream**: ALLOW. Non puoi pubblicare alcuna versione del pacchetto direttamente nel tuo repository.
## Attacchi di sostituzione delle dipendenze
I Package Manager semplificano il processo di imballaggio e condivisione del codice riutilizzabile. Questi pacchetti possono essere pacchetti privati sviluppati da un'organizzazione per essere utilizzati nelle proprie applicazioni, oppure possono essere pacchetti pubblici, in genere pacchetti open source sviluppati all'esterno di un'organizzazione e distribuiti da archivi di pacchetti pubblici. Quando richiedono pacchetti, gli sviluppatori si affidano al proprio gestore di pacchetti per recuperare nuove versioni delle proprie dipendenze. Gli attacchi di sostituzione delle dipendenze, noti anche come attacchi basati sulla confusione delle dipendenze, sfruttano il fatto che un gestore di pacchetti in genere non ha modo di distinguere le versioni legittime di un pacchetto da quelle dannose.
Gli attacchi di sostituzione delle dipendenze appartengono a un sottoinsieme di attacchi noti come attacchi alla catena di fornitura del software. Un attacco alla catena di fornitura del software è un attacco che sfrutta le vulnerabilità in qualsiasi punto della catena di fornitura del software.
Un attacco basato sulla sostituzione delle dipendenze può colpire chiunque utilizzi sia pacchetti sviluppati internamente sia pacchetti recuperati da archivi pubblici. Gli aggressori identificano i nomi interni dei pacchetti e quindi posizionano strategicamente il codice dannoso con lo stesso nome negli archivi pubblici dei pacchetti. In genere, il codice dannoso viene pubblicato in un pacchetto con un numero di versione elevato. I gestori di pacchetti recuperano il codice dannoso da questi feed pubblici perché ritengono che i pacchetti dannosi siano le versioni più recenti del pacchetto. Ciò causa una «confusione» o una «sostituzione» tra il pacchetto desiderato e il pacchetto dannoso, con conseguente compromissione del codice.
Per prevenire attacchi di sostituzione delle dipendenze, Amazon CodeCatalyst fornisce controlli sull'origine dei pacchetti. I controlli di origine dei pacchetti sono impostazioni che controllano il modo in cui i pacchetti possono essere aggiunti ai repository. I controlli vengono configurati automaticamente quando la prima versione del pacchetto di un nuovo pacchetto viene aggiunta a un CodeCatalyst repository. I controlli possono garantire che le versioni dei pacchetti non possano essere sia pubblicate direttamente nel repository sia importate da fonti pubbliche, proteggendo così l'utente dagli attacchi di sostituzione delle dipendenze. Per ulteriori informazioni sui controlli di origine dei pacchetti e su come modificarli, consulta. [Modifica dei controlli di origine dei pacchetti](#package-origin-controls)
# Utilizzo di npm
Questi argomenti descrivono come è possibile utilizzare `npm` il gestore di pacchetti Node.js con CodeCatalyst.
**Nota**
CodeCatalyst supporta `node v4.9.1` e versioni successive `npm v5.0.0` e successive.
**Topics**
+ [Configurazione e utilizzo di npm](packages-npm-use.md)
+ [gestione dei tag npm](packages-npm-tags.md)
# Configurazione e utilizzo di npm
Per `npm` utilizzarlo CodeCatalyst, è necessario connettersi `npm` al repository dei pacchetti e fornire un token di accesso personale (PAT) per l'autenticazione. È possibile visualizzare le istruzioni per la connessione `npm` al repository dei pacchetti nella console. CodeCatalyst
**Contents**
+ [Configurazione di npm con CodeCatalyst](#npm-configure)
+ [Installazione dei pacchetti npm da un archivio di pacchetti CodeCatalyst](#npm-install)
+ [Installazione dei pacchetti npm da npmjs tramite CodeCatalyst](#npm-install-npmjs)
+ [Pubblicazione di pacchetti npm nel tuo repository di pacchetti CodeCatalyst](#npm-publish)
+ [supporto ai comandi npm](#npm-commands)
+ [Comandi supportati che interagiscono con un archivio di pacchetti](#supported-commands-that-interact-with-a-repository)
+ [Comandi lato client supportati](#supported-client-side-commands)
+ [Comandi non supportati](#unsupported-commands)
## Configurazione di npm con CodeCatalyst
Le seguenti istruzioni spiegano come autenticarsi e connettersi `npm` al repository dei pacchetti. CodeCatalyst Per ulteriori informazioni su npm, consulta la documentazione [ufficiale](https://docs.npmjs.com/) di npm.
**Per connetterti `npm` al tuo repository di pacchetti CodeCatalyst**
1. Apri la CodeCatalyst console all'indirizzo [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Vai al tuo progetto.
1. Nel riquadro di navigazione scegliere **Pacchetti**.
1. Scegli il tuo repository di pacchetti dall'elenco.
1. Scegli **Connect to repository.**
1. Nei **dettagli di configurazione**, in **Package manager client**, scegli **npm client**.
1. Scegli il tuo sistema operativo per visualizzare i passaggi di configurazione corrispondenti.
1. È necessario un token di accesso personale (PAT) per autenticare npm con. CodeCatalyst Se hai già un token, puoi usarlo. In caso contrario, puoi crearne uno utilizzando i seguenti passaggi.
1. **(Facoltativo):** aggiorna il **nome e la **data di scadenza** del PAT**.
1. Scegli **Crea token**.
1. Copia e archivia il tuo PAT in un luogo sicuro.
**avvertimento**
Non potrai più vedere o copiare il tuo PAT dopo aver chiuso la finestra di dialogo. Le credenziali devono essere di breve durata per ridurre al minimo il periodo di tempo in cui un utente malintenzionato può utilizzarle dopo averle sottratte indebitamente.
1. Esegui i seguenti comandi dalla directory principale del tuo progetto per configurare npm con il tuo repository di pacchetti. I comandi faranno quanto segue:
+ Crea un `.npmrc` file a livello di progetto se il tuo progetto non ne ha uno.
+ Aggiungi le informazioni sull'endpoint del repository del pacchetto al file a livello di progetto. `.npmrc`
+ Aggiungi le tue credenziali (PAT) al tuo file a livello utente. `.npmrc`
Sostituisci i seguenti valori.
**Nota**
Se state copiando le istruzioni dalla console, i valori dei seguenti comandi vengono aggiornati automaticamente e non è necessario modificarli.
+ *username*Sostituiscilo con il tuo nome CodeCatalyst utente.
+ *PAT*Sostituiscilo con il tuo CodeCatalyst PAT.
+ *space\$1name*Sostituiscilo con il nome CodeCatalyst dello spazio.
+ *proj\$1name*Sostituiscilo con il nome CodeCatalyst del tuo progetto.
+ *repo\$1name*Sostituiscilo con il nome CodeCatalyst del repository dei pacchetti.
```
npm set registry=https://packages.region.codecatalyst.aws/npm/space-name/proj-name/repo-name/ --location project
npm set //packages.region.codecatalyst.aws/npm/space-name/proj-name/repo-name/:_authToken=username:PAT
```
**Per npm 6 o versioni precedenti:** per fare in modo che npm passi sempre il token di autenticazione a CodeCatalyst, anche per `GET` le richieste, imposta la variabile di configurazione always-auth come segue. `npm config set`
```
npm set //packages.region.codecatalyst.aws/npm/space-name/proj-name/repo-name/:always-auth=true --location project
```
## Installazione dei pacchetti npm da un archivio di pacchetti CodeCatalyst
Dopo aver collegato npm al tuo repository seguendo i passaggi indicati[Configurazione di npm con CodeCatalyst](#npm-configure), puoi eseguire `npm` comandi sul tuo repository.
Puoi installare un pacchetto npm che si trova nel tuo repository di CodeCatalyst pacchetti o in uno dei suoi repository upstream con il comando. `npm install`
```
npm install lodash
```
## Installazione dei pacchetti npm da npmjs tramite CodeCatalyst
È possibile installare i pacchetti npm da [npmjs.com](https://www.npmjs.com/) tramite un CodeCatalyst repository configurando il repository con una connessione upstream al repository gateway collegato a npmjs.com,. **npm-public-registry-gateway** I pacchetti installati da npmjs vengono inseriti e archiviati nel repository del gateway e nel repository di pacchetti più lontano a valle.
**Per installare pacchetti da npmjs**
1. Se non l'hai già fatto, esegui la configurazione `npm` con il tuo repository di CodeCatalyst pacchetti seguendo i passaggi riportati di seguito. [Configurazione di npm con CodeCatalyst](#npm-configure)
1. Verifica che il tuo repository abbia aggiunto il repository gateway come connessione **npm-public-registry-gateway**upstream. Puoi verificare quali sorgenti upstream vengono aggiunte o aggiungerle **npm-public-registry-gateway**come sorgente upstream seguendo le istruzioni contenute [Aggiunta di un repository upstream](packages-upstream-repositories-add.md) e scegliendo il repository. **npm-public-registry-gateway**
1. Installa i pacchetti con il comando. `npm install`
```
npm install package_name
```
Per ulteriori informazioni sulla richiesta di pacchetti dai repository upstream, vedere. [Richiesta di una versione del pacchetto con repository upstream](packages-upstream-repositories-request.md)
## Pubblicazione di pacchetti npm nel tuo repository di pacchetti CodeCatalyst
Dopo aver completato[Configurazione di npm con CodeCatalyst](#npm-configure), puoi eseguire `npm` i comandi.
È possibile pubblicare un pacchetto npm in un repository di CodeCatalyst pacchetti con il `npm publish` comando.
```
npm publish
```
*Per informazioni su come creare pacchetti npm, vedere [Creazione di moduli Node.js](https://docs.npmjs.com/getting-started/creating-node-modules) su npm Docs.*
## supporto ai comandi npm
Le sezioni seguenti riassumono i `npm` comandi supportati dai repository di CodeCatalyst pacchetti, oltre a elencare comandi specifici che non sono supportati.
**Topics**
+ [Comandi supportati che interagiscono con un archivio di pacchetti](#supported-commands-that-interact-with-a-repository)
+ [Comandi lato client supportati](#supported-client-side-commands)
+ [Comandi non supportati](#unsupported-commands)
### Comandi supportati che interagiscono con un archivio di pacchetti
Questa sezione elenca `npm` i comandi in cui il `npm` client effettua una o più richieste al registro in cui è configurato (ad esempio,`npm config set registry`). È stato verificato che questi comandi funzionino correttamente quando vengono richiamati CodeCatalyst su un archivio di pacchetti.
****
| Comando | Description |
| --- | --- |
| [bug](https://docs.npmjs.com/cli/bugs) | Indovina la posizione dell'URL del bug tracker di un pacchetto, quindi tenta di aprirlo. |
| [ci](https://docs.npmjs.com/cli/ci) | Installa un progetto con una tabula rasa. |
| [deprecare](https://docs.npmjs.com/cli/deprecate) | Depreca una versione di un pacchetto. |
| [dist-tag](https://docs.npmjs.com/cli/dist-tag) | Modifica i tag di distribuzione dei pacchetti. |
| [documenti](https://docs.npmjs.com/cli/docs) | Indovina la posizione dell'URL della documentazione di un pacchetto, quindi tenta di aprirlo utilizzando il `--browser` parametro config. |
| [dottore](https://docs.npmjs.com/cli/doctor) | Esegue una serie di controlli per verificare che l'installazione di npm sia in grado di gestire i JavaScript pacchetti. |
| [installa](https://docs.npmjs.com/cli/install) | Installa un pacchetto. |
| [install-ci-test](https://docs.npmjs.com/cli/install-ci-test) | Installa un progetto con una lavagna pulita ed esegue dei test. Pseudonimo:. `npm cit` Questo comando esegue un`npm ci`, seguito immediatamente da un`npm test`. |
| [install-test](https://docs.npmjs.com/cli/install-test) | Installa il pacchetto ed esegue i test. Esegue un`npm install`, seguito immediatamente da un`npm test`. |
| [obsoleto](https://docs.npmjs.com/cli/outdated) | Controlla il registro configurato per determinare se i pacchetti installati sono obsoleti. |
| [ping](https://docs.npmjs.com/cli/ping) | Esegue il ping del registro npm configurato o specificato e verifica l'autenticazione. |
| [pubblica](https://docs.npmjs.com/cli/publish) | Pubblica una versione del pacchetto nel registro. |
| [update](https://docs.npmjs.com/cli/update) | Indovina la posizione dell'URL del repository di un pacchetto, quindi tenta di aprirlo utilizzando il parametro config. `--browser` |
| [visualizzare](https://docs.npmjs.com/cli/view) | Visualizza i metadati del pacchetto. Può essere utilizzato anche per stampare le proprietà dei metadati. |
### Comandi lato client supportati
Questi comandi non richiedono alcuna interazione diretta con un repository di pacchetti, quindi CodeCatalyst non richiedono nulla per supportarli.
****
| Comando | Description |
| --- | --- |
| [bin (legacy)](https://docs.npmjs.com/cli/v8/commands/npm-bin) | Visualizza la `bin` directory npm. |
| [costruire](https://docs.npmjs.com/cli/v6/commands/npm-build) | Costruisce un pacchetto. |
| [cache](https://docs.npmjs.com/cli/cache) | Manipola la cache dei pacchetti. |
| [completamento](https://docs.npmjs.com/cli/completion) | Abilita il completamento delle schede in tutti i comandi npm. |
| [config](https://docs.npmjs.com/cli/config) | Aggiorna il contenuto dell'utente e dei `npmrc` file globali. |
| [deduplicare](https://docs.npmjs.com/cli/dedupe) | Cerca nell'albero dei pacchetti locale e tenta di semplificare la struttura spostando le dipendenze più in alto nell'albero, dove possono essere condivise più efficacemente da più pacchetti dipendenti. |
| [modifica](https://docs.npmjs.com/cli/edit) | Modifica un pacchetto installato. Seleziona una dipendenza nella directory di lavoro corrente e apre la directory dei pacchetti nell'editor predefinito. |
| [esplora](https://docs.npmjs.com/cli/explore) | Sfoglia un pacchetto installato. Genera una subshell nella directory del pacchetto installato specificato. Se viene specificato un comando, questo viene eseguito nella sottoshell, che si spegne immediatamente. |
| [help](https://docs.npmjs.com/cli/help) | Ottiene aiuto su npm. |
| [aiuto-ricerca](https://docs.npmjs.com/cli/help-search) | Cerca nella documentazione di aiuto di npm. |
| [init](https://docs.npmjs.com/cli/init) | Crea un `package.json` file. |
| [collegamento](https://docs.npmjs.com/cli/link) | Collega simbolicamente una cartella di pacchetti. |
| [ls](https://docs.npmjs.com/cli/ls) | Elenca i pacchetti installati. |
| [pacchetto](https://docs.npmjs.com/cli/pack) | Crea un archivio tar da un pacchetto. |
| [prefisso](https://docs.npmjs.com/cli/prefix) | Visualizza un prefisso. Questa è la directory principale più vicina a contenere un `package.json` file, a meno che non `-g` sia specificata anche questa. |
| [prugna](https://docs.npmjs.com/cli/prune) | Rimuove i pacchetti che non sono elencati nell'elenco delle dipendenze del pacchetto principale. |
| [ricostruire](https://docs.npmjs.com/cli/rebuild) | Esegue il `npm build` comando sulle cartelle corrispondenti. |
| [riavviare](https://docs.npmjs.com/cli/restart) | Esegue gli script di arresto, riavvio e avvio di un pacchetto e i pre-script e post-script associati. |
| [root](https://docs.npmjs.com/cli/root) | Stampa la directory effettiva per renderla standard`node_modules`. |
| [esegui script](https://docs.npmjs.com/cli/run-script) | Esegue script di pacchetti arbitrari. |
| [pellicola shrinkwrap](https://docs.npmjs.com/cli/shrinkwrap) | Blocca le versioni dipendenti per la pubblicazione. |
| [disinstallare](https://docs.npmjs.com/cli/uninstall) | Disinstalla un pacchetto. |
### Comandi non supportati
Questi `npm` comandi non sono supportati dagli archivi dei CodeCatalyst pacchetti.
****
| Comando | Description | Note |
| --- | --- | --- |
| [accesso](https://docs.npmjs.com/cli/access) | Imposta il livello di accesso sui pacchetti pubblicati. | CodeCatalyst utilizza un modello di autorizzazione diverso dal repository pubblico npmjs. |
| [aggiungi utente](https://docs.npmjs.com/cli/adduser) | Aggiunge un account utente del registro | CodeCatalyst utilizza un modello utente diverso dal repository pubblico npmjs. |
| [audit](https://docs.npmjs.com/cli/audit) | Esegue un controllo di sicurezza. | CodeCatalyst attualmente non vende dati sulle vulnerabilità di sicurezza. |
| [gancio](https://docs.npmjs.com/cli/v9/commands/npm-hook) | Gestisce gli hook di npm, inclusi l'aggiunta, la rimozione, l'elenco e l'aggiornamento. | CodeCatalyst attualmente non supporta alcun meccanismo di notifica delle modifiche. |
| [Login](https://docs.npmjs.com/cli-commands/adduser.html) | Autentica un utente. Questo è un alias per `npm adduser`. | CodeCatalyst utilizza un modello di autenticazione diverso dal repository pubblico npmjs. Per informazioni, consulta [Configurazione di npm con CodeCatalyst](#npm-configure). |
| [Disconnessione](https://docs.npmjs.com/cli/logout) | Si disconnette dal registro. | CodeCatalyst utilizza un modello di autenticazione diverso dal repository pubblico npmjs. Non è possibile disconnettersi da un CodeCatalyst repository, ma i token di autenticazione scadono dopo la data di scadenza configurabile. La durata predefinita del token è di 12 ore. |
| [proprietario](https://docs.npmjs.com/cli/owner) | Gestisce i proprietari dei pacchetti. | CodeCatalyst utilizza un modello di autorizzazioni diverso dal repository pubblico npmjs. |
| [profile](https://docs.npmjs.com/cli/profile) | Modifica le impostazioni sul profilo del registro. | CodeCatalyst utilizza un modello utente diverso dal repository pubblico npmjs. |
| [cerca](https://docs.npmjs.com/cli/search) | Cerca nel registro i pacchetti che corrispondono ai termini di ricerca. | CodeCatalyst non supporta il `search` comando. |
| [stella](https://docs.npmjs.com/cli/star) | Contrassegna i tuoi pacchetti preferiti. | CodeCatalyst attualmente non supporta alcun meccanismo di creazione di preferiti. |
| [stelle](https://docs.npmjs.com/cli/stars) | Visualizza i pacchetti contrassegnati come preferiti. | CodeCatalyst attualmente non supporta alcun meccanismo di creazione di preferiti. |
| [squadra](https://docs.npmjs.com/cli/team) | Gestisce i team e le appartenenze ai team. | CodeCatalyst utilizza un modello di appartenenza di utenti e gruppi diverso dal repository pubblico npmjs. |
| [t](https://docs.npmjs.com/cli/token)oken | Gestisce i token di autenticazione. | CodeCatalyst utilizza un modello diverso per ottenere i token di autenticazione. Per informazioni, consulta [Configurazione di npm con CodeCatalyst](#npm-configure). |
| [annullare la pubblicazione](https://docs.npmjs.com/cli/unpublish) | Rimuove un pacchetto dal registro. | CodeCatalyst non supporta la rimozione di una versione del pacchetto da un repository utilizzando il client npm. È possibile eliminare un pacchetto nella console. |
| [whoami](https://docs.npmjs.com/cli/whoami) | Visualizza il nome utente npm. | CodeCatalyst utilizza un modello utente diverso dal repository pubblico npmjs. |
# gestione dei tag npm
I registri npm supportano i *tag*, che sono alias di stringa per le versioni dei pacchetti. È possibile utilizzare i tag per fornire un alias invece di utilizzare i numeri di versione. Ad esempio, hai un progetto con più flussi di sviluppo e utilizzi un tag diverso per ogni flusso (ad esempio,, `stable` `beta``dev`,`canary`). *Per ulteriori informazioni, consulta [dist-tag](https://docs.npmjs.com/cli/dist-tag) su npm Docs.*
Per impostazione predefinita, npm utilizza il `latest` tag per identificare la versione corrente di un pacchetto. `npm install pkg`(senza `@version` o `@tag` specificatore) installa il tag più recente. In genere, i progetti utilizzano solo il tag più recente per le versioni di rilascio stabili. Altri tag vengono utilizzati per le versioni instabili o non definitive.
## Modifica dei tag con il client npm
I tre `npm dist-tag` comandi (`add``rm`, e`ls`) funzionano allo stesso modo nei repository di CodeCatalyst pacchetti come funzionano nel registro [npm predefinito](https://registry.npmjs.com/).
## tag npm e repository upstream
Quando `npm` richiede, i tag per un pacchetto e le versioni di quel pacchetto sono presenti anche in un repository upstream, CodeCatalyst unisce i tag prima di restituirli al client. Ad esempio, un repository denominato `R` ha un repository upstream denominato. `U` La tabella seguente mostra i tag per un pacchetto denominato presente in `web-helper` entrambi i repository.
****
| Repository | Nome pacchetto | Tag del pacchetto |
| --- | --- | --- |
| R | `web-helper` | *più recente* (alias per la versione 1.0.0) |
| U | `web-helper` | *alpha* (alias per la versione 1.0.1) |
**In questo caso, quando il client npm recupera i tag per il `web-helper` pacchetto dal repository`R`, riceve sia i tag più recenti che quelli alpha.** Le versioni a cui puntano i tag non cambieranno.
Quando lo stesso tag è presente sullo stesso pacchetto sia nell'archivio originale che in quello locale, CodeCatalyst utilizza il tag che è stato aggiornato l'*ultima volta*. Ad esempio, supponiamo che i tag su *webhelper* siano stati modificati in modo da assomigliare ai seguenti.
****
| Repository | Nome pacchetto | Tag del pacchetto | Ultimo aggiornamento |
| --- | --- | --- | --- |
| R | `web-helper` | *più recente* (alias per la versione 1.0.0) | 1 gennaio 2023 |
| U | `web-helper` | *più recente* (alias per la versione 1.0.1) | 1 giugno 2023 |
*In questo caso, quando il client npm recupera i tag per il pacchetto *web-helper* dal repository`R`, l'ultimo tag assumerà l'alias della *versione 1.0.1 perché è stato aggiornato per ultima*.* Ciò semplifica l'utilizzo di nuove versioni di pacchetti in un repository upstream che non sono ancora presenti in un repository locale mediante l'esecuzione. `npm update`
# Usare Maven
Il formato di repository Maven è utilizzato da molti linguaggi diversi, tra cui Java, Kotlin, Scala e Clojure. È supportato da molti strumenti di compilazione diversi, tra cui Maven, Gradle, Scala SBT, Apache Ivy e Leiningen.
Abbiamo testato e confermato la compatibilità con le seguenti versioni: CodeCatalyst
+ Ultima versione di **Maven**: 3.6.3.
+ Ultima versione di **Gradle**: 6.4.1. Anche la versione 5.5.1 è stata testata.
**Topics**
+ [Configurazione e utilizzo di Gradle Groovy](packages-maven-gradle.md)
+ [Configurazione e utilizzo di mvn](packages-maven-mvn.md)
+ [Pacchetti di pubblicazione con curl](packages-maven-curl.md)
+ [Utilizzo dei checksum e delle istantanee di Maven](packages-maven-checksums-snapshots.md)
# Configurazione e utilizzo di Gradle Groovy
Per utilizzare Gradle Groovy con CodeCatalyst, devi connettere Gradle Groovy al tuo repository di pacchetti e fornire un token di accesso personale (PAT) per l'autenticazione. Puoi visualizzare le istruzioni per connettere Gradle Groovy al tuo repository di pacchetti nella console. CodeCatalyst
**Contents**
+ [Recupero delle dipendenze da CodeCatalyst](#gradle-fetch-dependencies)
+ [Recupero di plugin da CodeCatalyst](#gradle-fetch-plugins)
+ [Recupero di pacchetti da archivi di pacchetti esterni tramite CodeCatalyst](#gradle-install-public)
+ [Pubblicazione di pacchetti su CodeCatalyst](#gradle-publish-packages)
+ [Esecuzione di una build Gradle in IntelliJ IDEA](#gradle-intellij)
+ [Metodo 1: inserisci il PAT `gradle.properties`](#gradle-intellij-gradle-properties)
+ [Metodo 2: inserisci il PAT in un file separato](#gradle-intellij-file)
## Recupero delle dipendenze da CodeCatalyst
Le seguenti istruzioni spiegano come configurare Gradle Groovy per recuperare le dipendenze dal repository dei pacchetti. CodeCatalyst
**Per usare Gradle Groovy per recuperare le dipendenze dal tuo repository di pacchetti CodeCatalyst**
1. [Apri la console all'indirizzo https://codecatalyst.aws/. CodeCatalyst ](https://codecatalyst.aws/)
1. Vai al tuo progetto.
1. Nel riquadro di navigazione scegliere **Pacchetti**.
1. Scegli il tuo repository di pacchetti dall'elenco dei repository di pacchetti.
1. Scegli **Connect to repository.**
1. Nella finestra di dialogo **Connect to repository**, scegli **Gradle Groovy** dall'elenco dei client del gestore di pacchetti.
1. Avrai bisogno di un token di accesso personale (PAT) con cui autenticare Gradle Groovy. CodeCatalyst Se ne hai già uno, puoi usarlo. In caso contrario, puoi crearne uno qui.
1. Scegli **Crea token**.
1. Scegli **Copia** per copiare il tuo PAT.
**avvertimento**
Non potrai più vedere o copiare il tuo PAT dopo aver chiuso la finestra di dialogo.
1. Aggiorna il file delle proprietà di gradle con le tue credenziali di accesso. *username*Sostituiscilo con il tuo CodeCatalyst nome utente e sostituiscilo *PAT* con il tuo token di accesso CodeCatalyst personale. È possibile utilizzare qualsiasi valore per *spaceUsername* e *spacePassword* purché si utilizzino gli stessi valori nei passaggi seguenti.
```
spaceUsername=username
spacePassword=PAT
```
1. Per recuperare le dipendenze da CodeCatalyst una build di Gradle, copia lo snippet di `maven` codice e aggiungilo alla `repositories` sezione del file del progetto. `build.gradle` Sostituisci i seguenti valori. È possibile utilizzare qualsiasi valore *spaceName* purché si utilizzino gli stessi valori nei passaggi seguenti.
**Nota**
Se si copiano le istruzioni dalla console, i seguenti valori devono essere aggiornati automaticamente e non devono essere modificati.
+ *space\$1name*Sostituiscili con il nome CodeCatalyst dello spazio.
+ *proj\$1name*Sostituiscilo con il nome CodeCatalyst del tuo progetto.
+ *repo\$1name*Sostituiscilo con il nome CodeCatalyst del repository dei pacchetti.
```
maven {
name = 'spaceName'
url = uri('https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/')
credentials(PasswordCredentials)
}
```
1. (Facoltativo) Per utilizzare l'archivio dei CodeCatalyst pacchetti come unica fonte per le dipendenze del progetto, rimuovete tutte le altre sezioni dei repository dal file. `build.gradle` Se avete più di un repository, Gradle cerca in ogni repository le dipendenze nell'ordine in cui sono elencate.
## Recupero di plugin da CodeCatalyst
[Per impostazione predefinita, Gradle risolverà i plugin dal Gradle Plugin Portal pubblico.](https://plugins.gradle.org/) I seguenti passaggi configurano il progetto Gradle per risolvere i plugin dal repository dei pacchetti. CodeCatalyst
**Per usare Gradle per recuperare i plugin dal tuo repository di pacchetti CodeCatalyst**
1. [Apri la console all'indirizzo https://codecatalyst.aws/ CodeCatalyst .](https://codecatalyst.aws/)
1. Vai al tuo progetto.
1. Nel riquadro di navigazione scegliere **Pacchetti**.
1. Scegli il tuo repository di pacchetti dall'elenco dei repository di pacchetti.
1. Scegli **Connect to repository.**
1. Nella finestra di dialogo **Connect to repository**, scegli **Gradle** dall'elenco dei client del gestore di pacchetti.
1. Avrai bisogno di un token di accesso personale (PAT) con cui autenticare Gradle. CodeCatalyst Se ne hai già uno, puoi usarlo. In caso contrario, puoi crearne uno qui.
1. Scegli **Crea token**.
1. Scegli **Copia** per copiare il tuo PAT.
**avvertimento**
Non potrai più vedere o copiare il tuo PAT dopo aver chiuso la finestra di dialogo.
1. Aggiorna il file delle proprietà di gradle con le tue credenziali di accesso. *username*Sostituiscilo con il tuo CodeCatalyst nome utente e sostituiscilo *PAT* con il tuo token di accesso CodeCatalyst personale. È possibile utilizzare qualsiasi valore per *spaceUsername* e *spacePassword* purché si utilizzino gli stessi valori nei passaggi seguenti.
```
spaceUsername=username
spacePassword=PAT
```
1. Aggiungi un `pluginManagement` blocco al tuo `settings.gradle` file. Il `pluginManagement` blocco deve apparire prima di qualsiasi altra istruzione in`settings.gradle`. Sostituisci i seguenti valori.
**Nota**
Se si copiano le istruzioni dalla console, i seguenti valori devono essere aggiornati automaticamente e non devono essere modificati.
+ Sostituire *spaceName* con il valore del nome utilizzato nel passaggio precedente.
+ *space\$1name*Sostituiscilo con il nome CodeCatalyst dello spazio.
+ *proj\$1name*Sostituiscilo con il nome CodeCatalyst del tuo progetto.
+ *repo\$1name*Sostituiscilo con il nome CodeCatalyst del repository dei pacchetti.
```
pluginManagement {
repositories {
maven {
name = 'spaceName'
url = uri('https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/')
credentials(PasswordCredentials)
}
}
}
```
Ciò assicurerà che Gradle risolva i plugin dal repository specificato. Il repository deve avere una connessione upstream configurata al Gradle Plugin Portal (`gradle-plugins-store`) in modo che i plugin Gradle comunemente richiesti siano disponibili per la build. [Per ulteriori informazioni, consultate la documentazione di Gradle.](https://docs.gradle.org/current/userguide/plugins.html#sec:custom_plugin_repositories)
## Recupero di pacchetti da archivi di pacchetti esterni tramite CodeCatalyst
È possibile installare i pacchetti Maven dai repository pubblici tramite un CodeCatalyst repository configurandolo con una connessione upstream al gateway che rappresenta il repository del gateway. I pacchetti installati dal repository del gateway vengono inseriti e archiviati nel repository dell'utente. CodeCatalyst
CodeCatalyst supporta i seguenti archivi pubblici di pacchetti Maven.
+ maven-central-gateway
+ google-android-gateway
+ gradle-plugins-gateway
+ commonsware-gateway
**Per installare pacchetti dagli archivi pubblici di pacchetti Maven**
1. Se non l'hai già fatto, configura Gradle con il tuo repository di CodeCatalyst pacchetti seguendo i passaggi in o. [Recupero delle dipendenze da CodeCatalyst](#gradle-fetch-dependencies) [Recupero di plugin da CodeCatalyst](#gradle-fetch-plugins)
1. Assicurati che il tuo repository abbia aggiunto il repository gateway da cui desideri installare come connessione upstream. Puoi farlo seguendo le istruzioni riportate [Aggiunta di un repository upstream](packages-upstream-repositories-add.md) e scegliendo il repository pubblico di pacchetti che desideri aggiungere come upstream.
Per ulteriori informazioni sulla richiesta di pacchetti dagli archivi upstream, consulta. [Richiesta di una versione del pacchetto con repository upstream](packages-upstream-repositories-request.md)
## Pubblicazione di pacchetti su CodeCatalyst
Questa sezione descrive come pubblicare una libreria Java creata con Gradle Groovy in un repository. CodeCatalyst
**Per usare Gradle Groovy per pubblicare pacchetti in un repository di pacchetti CodeCatalyst**
1. [Apri la console all'indirizzo https://codecatalyst.aws/ CodeCatalyst .](https://codecatalyst.aws/)
1. Nella pagina di panoramica del progetto, scegli **Pacchetti**.
1. Scegli il tuo repository di pacchetti dall'elenco dei repository di pacchetti.
1. Scegli **Connect to repository.**
1. Nella finestra di dialogo **Connect to repository**, scegli **Gradle Groovy** dall'elenco dei client del gestore di pacchetti.
1. Avrai bisogno di un token di accesso personale (PAT) con cui autenticare Gradle. CodeCatalyst Se ne hai già uno, puoi usarlo. In caso contrario, puoi crearne uno qui.
1. Scegli **Crea token**.
1. Scegli **Copia** per copiare il tuo PAT.
**avvertimento**
Non potrai più vedere o copiare il tuo PAT dopo aver chiuso la finestra di dialogo.
1. Aggiorna il file delle proprietà di gradle con le tue credenziali di accesso. *username*Sostituiscilo con il tuo CodeCatalyst nome utente e sostituiscilo *PAT* con il tuo token di accesso CodeCatalyst personale. È possibile utilizzare qualsiasi valore per *spaceUsername* e *spacePassword* purché si utilizzino gli stessi valori nei passaggi seguenti.
```
spaceUsername=username
spacePassword=PAT
```
1. Aggiungi il `maven-publish` plugin alla `plugins` sezione del `build.gradle` file del progetto.
```
plugins {
id 'java-library'
id 'maven-publish'
}
```
1. Quindi, aggiungi una `publishing` sezione al `build.gradle` file di progetto. Sostituite i seguenti valori.
**Nota**
Se si copiano le istruzioni dalla console, i seguenti valori devono essere aggiornati automaticamente e non devono essere modificati.
+ *space\$1name*Sostituiscili con il nome CodeCatalyst dello spazio.
+ *proj\$1name*Sostituiscilo con il nome CodeCatalyst del tuo progetto.
+ *repo\$1name*Sostituiscilo con il nome CodeCatalyst del repository dei pacchetti.
```
publishing {
publications {
mavenJava(MavenPublication) {
groupId = 'group-id'
artifactId = 'artifact-id'
version = 'version'
from components.java
}
}
repositories {
maven {
name = 'spaceName'
url = uri('https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/')
credentials(PasswordCredentials)
}
}
}
```
Il `maven-publish` plugin genera un file POM basato su `groupId``artifactId`, e `version` specificato nella `publishing` sezione.
1. Una volta `build.gradle` completate queste modifiche, esegui il comando seguente per creare il progetto e caricarlo nel repository.
```
./gradlew publish
```
1. Accedi all'archivio dei pacchetti nella CodeCatalyst console per verificare che il pacchetto sia stato pubblicato correttamente. Dovresti vedere il pacchetto nell'elenco dei **pacchetti** del tuo archivio dei pacchetti.
Per ulteriori informazioni, consulta questi argomenti sul sito Web di Gradle:
+ [Creazione di librerie Java](https://guides.gradle.org/building-java-libraries/)
+ [Pubblicazione di un progetto come modulo](https://docs.gradle.org/current/userguide/publishing_setup.html)
## Esecuzione di una build Gradle in IntelliJ IDEA
È possibile eseguire una build Gradle in IntelliJ IDEA da cui estrae le dipendenze. CodeCatalyst Per autenticare Gradle CodeCatalyst, è necessario utilizzare un token di accesso personale (PAT). Puoi archiviare il tuo CodeCatalyst PAT in un file separato `gradle.properties` o in un file separato a tua scelta.
### Metodo 1: inserisci il PAT `gradle.properties`
Usa questo metodo se non stai usando il `gradle.properties` file e puoi sovrascriverne il contenuto con il tuo PAT. Se si utilizza`gradle.properties`, è possibile modificare questo metodo per aggiungere il PAT anziché sovrascrivere il contenuto del file.
**Nota**
L'esempio mostra il `gradle.properties` file che si trova in. `GRADLE_USER_HOME`
Innanzitutto, create un PAT se non ne avete uno.
**Per creare un token di accesso personale (PAT)**
1. Nella barra dei menu in alto, scegli il badge del tuo profilo, quindi scegli **Le mie** impostazioni.
**Suggerimento**
Puoi anche trovare il tuo profilo utente accedendo alla pagina dei membri relativa a un progetto o a uno spazio e scegliendo il tuo nome dall'elenco dei membri.
1. Nel nome **PAT, inserisci un nome** descrittivo per il tuo PAT.
1. In **Data di scadenza**, lascia la data predefinita o scegli l'icona del calendario per selezionare una data personalizzata. La data di scadenza predefinita è un anno dalla data corrente.
1. Scegli **Create** (Crea).
Puoi anche creare questo token quando scegli **Clone repository come repository di origine**.
1. Salva il segreto PAT in un luogo sicuro.
**Importante**
Il segreto PAT viene visualizzato solo una volta. Non è possibile recuperarlo dopo aver chiuso la finestra.
Successivamente, aggiorna il `build.gradle` file con il seguente frammento:
```
repositories {
maven {
name = 'spaceName'
url = uri('https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/')
credentials(PasswordCredentials)
}
}
```
### Metodo 2: inserisci il PAT in un file separato
Usa questo metodo se non vuoi modificare il tuo `gradle.properties` file.
Innanzitutto, crea un PAT se non ne hai uno.
**Per creare un token di accesso personale (PAT)**
1. Nella barra dei menu in alto, scegli il badge del tuo profilo, quindi scegli **Le mie** impostazioni.
**Suggerimento**
Puoi anche trovare il tuo profilo utente accedendo alla pagina dei membri relativa a un progetto o a uno spazio e scegliendo il tuo nome dall'elenco dei membri.
1. Nel nome **PAT, inserisci un nome** descrittivo per il tuo PAT.
1. In **Data di scadenza**, lascia la data predefinita o scegli l'icona del calendario per selezionare una data personalizzata. La data di scadenza predefinita è un anno dalla data corrente.
1. Scegli **Create** (Crea).
Puoi anche creare questo token quando scegli **Clone repository come repository di origine**.
1. Salva il segreto PAT in un luogo sicuro.
**Importante**
Il segreto PAT viene visualizzato solo una volta. Non è possibile recuperarlo dopo aver chiuso la finestra.
**Per inserire il file PAT in un file separato**
1. Aggiorna il `build.gradle` file con il seguente frammento. Sostituisci e *repo\$1name* con il tuo nome CodeCatalyst utente*space\$1name*, *proj\$1name* il nome dello spazio, il nome del progetto e il nome del repository del pacchetto.
```
def props = new Properties()
file("fileName").withInputStream { props.load(it) }
repositories {
maven {
name = 'spaceName'
url = uri('https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/')
credentials(PasswordCredentials)
}
}
}
```
1. Scrivi il tuo PAT nel file che è stato specificato nel tuo `build.gradle` file:
```
echo "codecatalystArtifactsToken=PAT" > fileName
```
# Configurazione e utilizzo di mvn
Si utilizza il `mvn` comando per eseguire le build di Maven. È necessario configurare `mvn` per utilizzare l'archivio dei pacchetti e fornire un token di accesso personale (PAT) per l'autenticazione.
**Contents**
+ [Recupero delle dipendenze da CodeCatalyst](#mvn-fetch-dependencies)
+ [Recupero di pacchetti da archivi di pacchetti esterni tramite CodeCatalyst](#mvn-install-public)
+ [Pubblicazione di pacchetti su CodeCatalyst](#mvn-publish-packages)
+ [Pubblicazione di pacchetti di terze parti](#publishing-third-party-packages)
## Recupero delle dipendenze da CodeCatalyst
`mvn`Per configurare il recupero delle dipendenze da un CodeCatalyst repository, devi modificare il file di configurazione di Maven `settings.xml` e, facoltativamente, il file Project Model Object (POM) del tuo progetto. Il file POM contiene informazioni sul progetto e informazioni di configurazione per consentire a Maven di creare il progetto, come dipendenze, directory di compilazione, directory dei sorgenti, directory dei sorgenti di test, plug-in e obiettivi.
**Da usare per recuperare le `mvn` dipendenze dal repository dei pacchetti CodeCatalyst**
1. [Apri la CodeCatalyst console all'indirizzo https://codecatalyst.aws/.](https://codecatalyst.aws/)
1. Nella pagina di panoramica del progetto, scegli **Pacchetti**.
1. Scegli il tuo repository di pacchetti dall'elenco dei repository di pacchetti.
1. Scegli **Connect to repository.**
1. Nella finestra di dialogo **Connect to repository**, scegliete **mvn** dall'elenco dei client del gestore di pacchetti.
1. Avrai bisogno di un token di accesso personale (PAT) con cui autenticarti. `mvn` CodeCatalyst Se ne hai già uno, puoi usarlo. In caso contrario, puoi crearne uno qui.
1. Scegli **Crea token**.
1. Scegli **Copia** per copiare il tuo PAT.
**avvertimento**
Non potrai più vedere o copiare il tuo PAT dopo aver chiuso la finestra di dialogo.
1. Aggiungi un profilo contenente il tuo repository al tuo `settings.xml` file. Sostituisci i seguenti valori.
**Nota**
Se si copiano le istruzioni dalla console, i seguenti valori devono essere aggiornati automaticamente e non devono essere modificati.
+ *space\$1name*Sostituiscili con il nome CodeCatalyst dello spazio.
+ *proj\$1name*Sostituiscilo con il nome CodeCatalyst del tuo progetto.
+ *repo\$1name*Sostituiscilo con il nome CodeCatalyst del repository dei pacchetti.
```
repo_name
true
repo_name
https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/
```
1. Aggiungi il tuo server all'elenco dei server nel `settings.xml` file. Sostituisci i seguenti valori.
**Nota**
Se si copiano le istruzioni dalla console, i seguenti valori devono essere aggiornati automaticamente e non devono essere modificati.
+ *repo\$1name*Sostituiteli con il nome CodeCatalyst del repository dei pacchetti.
+ Sostituisci *username* con il tuo nome CodeCatalyst utente.
+ *PAT*Sostituiscilo con il tuo CodeCatalyst PAT.
```
repo_name
username
PAT
```
1. (Facoltativo) Imposta un mirror nel `settings.xml` file che acquisisca tutte le connessioni e le indirizzi al repository anziché a un repository gateway.
**Nota**
Se copiate le istruzioni dalla console, i seguenti valori devono essere aggiornati automaticamente e non devono essere modificati.
+ *space\$1name*Sostituiscili con il nome CodeCatalyst dello spazio.
+ *proj\$1name*Sostituiscilo con il nome CodeCatalyst del tuo progetto.
+ *repo\$1name*Sostituiscilo con il nome CodeCatalyst del repository dei pacchetti.
```
repo_name
repo_name
https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/
*
```
**Importante**
È possibile utilizzare qualsiasi valore nell'``elemento, ma deve essere lo stesso in entrambi `` gli `` elementi. Ciò consente di includere le credenziali specificate nelle richieste di CodeCatalyst.
Dopo aver apportato queste modifiche alla configurazione, puoi creare il progetto.
```
mvn compile
```
## Recupero di pacchetti da archivi di pacchetti esterni tramite CodeCatalyst
È possibile installare i pacchetti Maven dai repository pubblici tramite un CodeCatalyst repository configurandolo con una connessione upstream al gateway che rappresenta il repository del gateway. I pacchetti installati dal repository del gateway vengono inseriti e archiviati nel repository dell'utente. CodeCatalyst
Attualmente, CodeCatalyst supporta i seguenti archivi pubblici di pacchetti Maven.
+ maven-central-gateway
+ google-android-gateway
+ gradle-plugins-gateway
+ commonsware-gateway
**Per installare pacchetti dagli archivi pubblici di pacchetti Maven**
1. Se non l'hai già fatto, esegui la configurazione `mvn` con il tuo repository di CodeCatalyst pacchetti seguendo i passaggi riportati di seguito. [Recupero delle dipendenze da CodeCatalyst](#mvn-fetch-dependencies)
1. Assicurati che il tuo repository abbia aggiunto il repository gateway da cui desideri installare come connessione upstream. Per verificare quali sorgenti upstream vengono aggiunte o per aggiungere un repository gateway come sorgente upstream, segui le istruzioni riportate in. [Aggiunta di un repository upstream](packages-upstream-repositories-add.md)
Per ulteriori informazioni sulla richiesta di pacchetti dai repository upstream, consulta. [Richiesta di una versione del pacchetto con repository upstream](packages-upstream-repositories-request.md)
## Pubblicazione di pacchetti su CodeCatalyst
Per pubblicare un pacchetto Maven in un CodeCatalyst repository, devi anche modificare `~/.m2/settings.xml` e progettare POM. `mvn`
**Da usare per `mvn` pubblicare pacchetti nel tuo repository di pacchetti CodeCatalyst**
1. Apri la CodeCatalyst console all'indirizzo [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Nella pagina di panoramica del progetto, scegli **Pacchetti**.
1. Scegli il tuo repository di pacchetti dall'elenco dei repository di pacchetti.
1. Scegli **Connect to repository.**
1. Nella finestra di dialogo **Connect to repository**, scegliete **mvn** dall'elenco dei client del gestore di pacchetti.
1. Avrai bisogno di un token di accesso personale (PAT) con cui autenticarti. `mvn` CodeCatalyst Se ne hai già uno, puoi usarlo. In caso contrario, puoi crearne uno qui.
1. Scegli **Crea token**.
1. Scegli **Copia** per copiare il tuo PAT.
**avvertimento**
Non potrai più vedere o copiare il tuo PAT dopo aver chiuso la finestra di dialogo.
1. Configura una variabile di ambiente sul tuo computer locale con il tuo PAT. Utilizzerai questa variabile di ambiente nel tuo `setting.xml` file.
```
export CODECATALYST_ARTIFACTS_TOKEN=your_PAT
```
1. Aggiungi una `` sezione a `settings.xml` con un riferimento alla variabile di `CodeCatalyst_ARTIFACTS_TOKEN` ambiente in modo che Maven passi il token nelle richieste HTTP.
```
...
repo-name
username
${env.CodeCatalyst_ARTIFACTS_TOKEN}
...
```
1. Aggiungi una `` sezione a quella del tuo progetto. `pom.xml`
```
...
repo_name
repo_name
https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/
...
```
Dopo aver apportato queste modifiche alla configurazione, puoi creare il progetto e pubblicarlo nel repository specificato.
```
mvn deploy
```
È possibile accedere all'archivio dei pacchetti nella CodeCatalyst console per verificare che il pacchetto sia stato pubblicato correttamente.
## Pubblicazione di pacchetti di terze parti
Puoi pubblicare pacchetti Maven di terze parti in un CodeCatalyst repository con. `mvn deploy:deploy-file` Questo può essere utile per gli utenti che desiderano pubblicare pacchetti e dispongono solo di file JAR e non hanno accesso al codice sorgente del pacchetto o ai file POM.
Il `mvn deploy:deploy-file` comando genererà un file POM basato sulle informazioni passate nella riga di comando.
Innanzitutto, crea un PAT se non ne hai uno.
**Per creare un token di accesso personale (PAT)**
1. Nella barra dei menu in alto, scegli il badge del tuo profilo, quindi scegli **Le mie** impostazioni.
**Suggerimento**
Puoi anche trovare il tuo profilo utente accedendo alla pagina dei membri relativa a un progetto o a uno spazio e scegliendo il tuo nome dall'elenco dei membri.
1. Nel nome **PAT, inserisci un nome** descrittivo per il tuo PAT.
1. In **Data di scadenza**, lascia la data predefinita o scegli l'icona del calendario per selezionare una data personalizzata. La data di scadenza predefinita è un anno dalla data corrente.
1. Scegli **Create** (Crea).
Puoi anche creare questo token quando scegli **Clone repository come repository di origine**.
1. Salva il segreto PAT in un luogo sicuro.
**Importante**
Il segreto PAT viene visualizzato solo una volta. Non è possibile recuperarlo dopo aver chiuso la finestra.
**Per pubblicare pacchetti Maven di terze parti**
1. Crea un `~/.m2/settings.xml` file con i seguenti contenuti:
```
repo_name
username
PAT}
```
1. Eseguire il comando `mvn deploy:deploy-file`:
```
mvn deploy:deploy-file -DgroupId=commons-cli \
-DartifactId=commons-cli \
-Dversion=1.4 \
-Dfile=./commons-cli-1.4.jar \
-Dpackaging=jar \
-DrepositoryId=repo-name \
-Durl=https://packages.region.codecatalyst.aws/maven/space-name/proj-name/repo-name/
```
**Nota**
L'esempio precedente pubblica`commons-cli 1.4`. Modifica gli argomenti GroupiD, artifactID, version e file per pubblicare un JAR diverso.
*Queste istruzioni si basano su esempi contenuti nella [Guida alla distribuzione di terze parti in un repository remoto tratti dalla documentazione di JARs Apache](https://maven.apache.org/guides/mini/guide-3rd-party-jars-remote.html) Maven.*
Per ulteriori informazioni, consulta questi argomenti sul sito Web del progetto Apache Maven:
+ [Configurazione di più repository](https://maven.apache.org/guides/mini/guide-multiple-repositories.html)
+ [Riferimento alle impostazioni](https://maven.apache.org/settings.html)
+ [Gestione della distribuzione](https://maven.apache.org/pom.html#Distribution_Management)
+ [Profili](https://maven.apache.org/pom.html#Profiles)
# Pacchetti di pubblicazione con curl
Questa sezione mostra come usare il client HTTP per `curl` pubblicare pacchetti Maven in un CodeCatalyst repository di pacchetti. La pubblicazione di pacchetti con `curl` può essere utile se non si dispone o non si desidera installare il client Maven nei propri ambienti.
**Per pubblicare un pacchetto Maven con `curl`**
1. È necessario memorizzare un token di accesso personale (PAT) in una variabile di ambiente con cui eseguire l'autenticazione. `curl` CodeCatalyst Se ne hai già uno, puoi usarlo. In caso contrario, puoi crearne uno e configurare la variabile di ambiente.
1. Crea un PAT seguendo la procedura riportata di seguito. [Concedi agli utenti l'accesso al repository con token di accesso personali](ipa-tokens-keys.md) Copia il PAT per memorizzarlo in una variabile di ambiente.
1. Sulla riga di comando del computer locale, configura una variabile di ambiente con il tuo PAT.
```
export CodeCatalyst_ARTIFACTS_TOKEN=your_PAT
```
1. Usa il seguente `curl` comando per pubblicare il JAR in un CodeCatalyst repository. Sostituisci *username**space\$1name*,*proj\$1name*, e *repo\$1name* con il tuo nome CodeCatalyst utente, nome dello spazio, nome del progetto e nome del repository del pacchetto.
```
curl --request PUT https://packages.region.codecatalyst.aws/maven/space-name/proj-name/repo-name/com/mycompany/app/my-app/1.0/my-app-1.0.jar \
--user "username:CodeCatalyst_ARTIFACTS_TOKEN" --header "Content-Type: application/octet-stream" \
--data-binary @target/path/to/my-app-1.0.jar
```
1. Utilizzate il `curl` comando seguente per pubblicare il POM in un CodeCatalyst repository. Sostituisci *username**space\$1name*,*proj\$1name*, e *repo\$1name* con il tuo nome CodeCatalyst utente, nome dello spazio, nome del progetto e nome del repository del pacchetto.
```
curl --request PUT https://packages.region.codecatalyst.aws/maven/space-name/proj-name/repo-name/com/mycompany/app/my-app/1.0/my-app-1.0.pom \
--user "username:CodeCatalyst_ARTIFACTS_TOKEN" --header "Content-Type: application/octet-stream" \
--data-binary @target/my-app-1.0.pom
```
1. A questo punto, il pacchetto Maven sarà nel tuo CodeCatalyst repository con uno stato di. `Unfinished` Per poter consumare il pacchetto, deve trovarsi nello stato. `Published` Puoi spostare il pacchetto da `Unfinished` a `Published` caricando un `maven-metadata.xml` file nel pacchetto o modificando lo stato nella CodeCatalyst console.
1. Opzione 1: utilizza il seguente `curl` comando per aggiungere un `maven-metadata.xml` file al pacchetto. Sostituisci *username**space\$1name*,*proj\$1name*, e *repo\$1name* con il tuo nome CodeCatalyst utente, nome dello spazio, nome del progetto e nome del repository del pacchetto.
```
curl --request PUT https://packages.region.codecatalyst.aws/maven/space-name/proj-name/repo-name/com/mycompany/app/my-app/maven-metadata.xml \
--user "username:CodeCatalyst_ARTIFACTS_TOKEN" --header "Content-Type: application/octet-stream" \
--data-binary @target/maven-metadata.xml
```
Di seguito è riportato un esempio del contenuto di un `maven-metadata.xml` file:
```
com.mycompany.app
my-app
1.0
1.0
1.0
20200731090423
```
1. Opzione 2: aggiorna lo stato del pacchetto `Published` nella CodeCatalyst console. Per informazioni su come aggiornare lo stato di una versione del pacchetto, consulta[Aggiornamento dello stato di una versione del pacchetto](working-with-packages-update-version-status.md).
Se disponi solo del file JAR di un pacchetto, puoi pubblicare una versione consumabile del pacchetto in un CodeCatalyst repository utilizzando. `mvn` Ciò può essere utile se non si ha accesso al codice sorgente o al POM del pacchetto. Per informazioni dettagliate, vedi [Pubblicazione di pacchetti di terze parti](packages-maven-mvn.md#publishing-third-party-packages).
# Utilizzo dei checksum e delle istantanee di Maven
Le sezioni seguenti descrivono come utilizzare i checksum Maven e le istantanee Maven in. CodeCatalyst
## Utilizzo dei checksum Maven
Quando un pacchetto Maven viene pubblicato in un repository di pacchetti, il checksum associato a ogni *risorsa* o file del CodeCatalyst pacchetto viene utilizzato per convalidare il caricamento. *Esempi di risorse sono i file *jar*, *pom* e war.* Per ogni risorsa, il pacchetto Maven contiene più file di checksum che utilizzano il nome della risorsa con un'estensione aggiuntiva, ad esempio o. `md5` `sha1` Ad esempio, i file di checksum per un file denominato `my-maven-package.jar` potrebbero essere e. `my-maven-package.jar.md5` `my-maven-package.jar.sha1`
Ogni pacchetto Maven contiene anche un file. `maven-metadata.xml` Questo file deve essere caricato affinché una pubblicazione abbia successo. Se viene rilevata una mancata corrispondenza del checksum durante il caricamento di qualsiasi file di pacchetto, la pubblicazione si interrompe. Ciò potrebbe `maven-metadata.xml` impedire il caricamento. Quando ciò accade, lo stato del pacchetto Maven è impostato su. `Unfinished` Non è possibile scaricare risorse che fanno parte di un pacchetto con questo stato.
Tieni presente quanto segue in caso di mancata corrispondenza del checksum quando pubblichi un pacchetto Maven:
+ Se il checksum non corrisponde prima del caricamento, lo stato del pacchetto non `maven-metadata.xml` è impostato su. `Unfinished` Il pacchetto non è visibile e le sue risorse non possono essere consumate. In questo caso, provate una delle seguenti operazioni, quindi provate a scaricare nuovamente la risorsa.
+ Esegui nuovamente il comando che pubblica il pacchetto Maven. Questo potrebbe funzionare se un problema di rete ha danneggiato il file di checksum durante il download. Se il problema di rete viene risolto per il nuovo tentativo, il checksum corrisponde e il download ha esito positivo.
+ Se la ripubblicazione del pacchetto Maven non funziona, elimina il pacchetto e ripubblicalo.
+ Se il checksum non corrisponde dopo il caricamento, lo stato del pacchetto `maven-metadata.xml` è impostato su. `Published` Puoi utilizzare qualsiasi risorsa del pacchetto, incluse quelle con i checksum non corrispondenti. Quando scaricate una risorsa, il checksum generato da CodeCatalyst viene scaricato con essa. Se il file scaricato è associato a un codice di controllo non corrispondente, il relativo file di checksum scaricato potrebbe non corrispondere al checksum caricato al momento della pubblicazione del pacchetto.
## Utilizzo delle istantanee di Maven
Un'*istantanea* di Maven è una versione speciale di un pacchetto Maven che si riferisce all'ultimo codice filiale di produzione. È una versione di sviluppo che precede la versione di rilascio finale. È possibile identificare una versione istantanea di un pacchetto Maven dal suffisso `SNAPSHOT` aggiunto alla versione del pacchetto. Ad esempio, l'istantanea della versione è. `1.1` `1.1-SNAPSHOT` Per ulteriori informazioni, consulta [Cos'è una versione SNAPSHOT](https://maven.apache.org/guides/getting-started/index.html#What_is_a_SNAPSHOT_version)? sul sito Web del progetto Apache Maven.
CodeCatalyst supporta la pubblicazione e l'utilizzo di istantanee Maven. È possibile pubblicare un'istantanea Maven in un CodeCatalyst repository o, se si è connessi direttamente, in un repository upstream. Tuttavia, una versione snapshot sia in un repository di pacchetti che in uno dei relativi repository upstream non è supportata. Ad esempio, se carichi un pacchetto Maven con versione `1.2-SNAPSHOT` nel tuo repository di pacchetti, CodeCatalyst non supporta il caricamento di un pacchetto Maven con la stessa versione di snapshot in uno dei suoi repository upstream. Questo scenario potrebbe restituire risultati imprevedibili.
*Quando viene pubblicata un'istantanea di Maven, la versione precedente viene conservata in una nuova versione chiamata build.* Ogni volta che viene pubblicata un'istantanea di Maven, viene creata una nuova versione di build. Tutte le versioni precedenti di un'istantanea vengono mantenute nelle relative versioni di build. Quando viene pubblicata un'istantanea di Maven, il suo stato viene impostato su `Published` e lo stato della build che contiene la versione precedente è impostato su. `Unlisted`
Se richiedi un'istantanea, viene restituita la versione con lo stato. `Published` Questa è sempre la versione più recente dell'istantanea di Maven. Puoi anche richiedere una build particolare di un'istantanea.
Per eliminare tutte le versioni di build di un'istantanea di Maven, usa la console. CodeCatalyst
# Usando NuGet
Questi argomenti descrivono come utilizzare e pubblicare `NuGet` pacchetti utilizzando CodeCatalyst.
**Nota**
CodeCatalyst supporta [NuGetla versione 4.8](https://docs.microsoft.com/en-us/nuget/release-notes/nuget-4.8-rtm) e successive.
**Topics**
+ [Utilizzo CodeCatalyst con Visual Studio](packages-nuget-visual-studio.md)
+ [Configurazione e utilizzo della CLI nuget o dotnet](packages-nuget-cli.md)
+ [NuGet normalizzazione del nome del pacchetto, della versione e del nome dell'asset](nuget-name-normalization.md)
+ [NuGet compatibilità](packages-nuget-compatibility.md)
# Utilizzo CodeCatalyst con Visual Studio
Puoi utilizzare i pacchetti CodeCatalyst direttamente da Visual Studio.
Per configurare e utilizzare NuGet con strumenti CLI come `dotnet` o`nuget`, vedere. [Configurazione e utilizzo della CLI nuget o dotnet](packages-nuget-cli.md)
**Contents**
+ [Configurazione di Visual Studio con CodeCatalyst](#packages-nuget-vs-configure)
+ [Windows](#packages-nuget-vs-configure-windows)
+ [macOS](#packages-nuget-vs-configure-mac)
## Configurazione di Visual Studio con CodeCatalyst
### Windows
**Per configurare Visual Studio con CodeCatalyst**
1. Per l'autenticazione è necessario un token di accesso personale (PAT) con. CodeCatalyst Se ne hai già uno, puoi usarlo. In caso contrario, segui le istruzioni [Concedi agli utenti l'accesso al repository con token di accesso personali](ipa-tokens-keys.md) per crearne uno.
1. Usa `nuget` o `dotnet` per configurare l'archivio dei pacchetti e le credenziali.
------
#### [ dotnet ]
**Utenti Linux e macOS:** poiché la crittografia non è supportata su piattaforme diverse da Windows, è necessario aggiungere il `--store-password-in-clear-text` flag al comando seguente. Tieni presente che in questo modo la password verrà memorizzata come testo semplice nel file di configurazione.
```
dotnet nuget add source https://packages.region.codecatalyst.aws/nuget/space-name/proj-name/repo-name/v3/index.json --name repo_name --password PAT --username user_name
```
------
#### [ nuget ]
```
nuget sources add -name repo_name -Source https://packages.region.codecatalyst.aws/nuget/space-name/proj-name/repo-name/v3/index.json -password PAT --username user_name
```
------
Output di esempio:
```
Package source with Name: repo_name added successfully.
```
1. Configura Visual Studio per utilizzare la nuova fonte del pacchetto. In Visual Studio, scegli **Strumenti**, quindi scegli **Opzioni**.
1. Nel menu **Opzioni**, espandi la sezione **NuGet Package Manager** e scegli **Package Sources**.
1. Nell'elenco **Sorgenti dei pacchetti disponibili**, assicurati che la tua *repo\$1name* fonte sia abilitata. Se hai configurato il tuo repository di pacchetti con una connessione upstream alla NuGet Galleria, disabilita il sorgente **nuget.org**.
### macOS
**Per configurare Visual Studio con CodeCatalyst**
1. Per l'autenticazione è necessario un token di accesso personale (PAT) con. CodeCatalyst Se ne hai già uno, puoi usarlo. In caso contrario, segui le istruzioni [Concedi agli utenti l'accesso al repository con token di accesso personali](ipa-tokens-keys.md) per crearne uno.
1. Scegli **Preferenze** dalla barra dei menu.
1. Nella **NuGet**sezione, scegli **Sorgenti**.
1. Scegli **Aggiungi e aggiungi** le informazioni del tuo repository.
1. In **Nome**, inserisci il nome CodeCatalyst del repository del pacchetto.
1. In **Ubicazione**, inserite l'endpoint CodeCatalyst del repository dei pacchetti. Il seguente frammento mostra un endpoint di esempio. Sostituisci *space-name* e *repo-name* con il nome CodeCatalyst dello spazio, il nome del progetto e il nome del repository. *proj-name*
```
https://packages.region.codecatalyst.aws/nuget/space-name/proj-name/repo-name/
```
1. Per **Nome utente**, inserisci un valore valido.
1. Per **Password**, inserisci il tuo PAT.
1. Scegliere **Add source (Aggiungi origine)**.
1. **Se hai configurato il tuo repository di pacchetti con una connessione upstream alla NuGet Galleria, disabilita il sorgente nuget.org.**
Dopo la configurazione, Visual Studio può utilizzare i pacchetti dal tuo CodeCatalyst repository, da uno qualsiasi dei suoi repository upstream o da [NuGet.org](https://www.nuget.org/) se lo hai configurato come sorgente upstream. Per altre informazioni sulla navigazione e l'installazione NuGet dei pacchetti in Visual Studio, vedi [Installare e gestire i pacchetti in Visual Studio utilizzando il NuGet Package Manager](https://docs.microsoft.com/en-us/nuget/consume-packages/install-use-packages-visual-studio) nella *NuGet documentazione*.
# Configurazione e utilizzo della CLI nuget o dotnet
È possibile utilizzare strumenti CLI come `NuGet` e `dotnet` da cui pubblicare e utilizzare pacchetti. CodeCatalyst Questo documento fornisce informazioni sulla configurazione degli strumenti CLI e sul loro utilizzo per pubblicare o utilizzare pacchetti.
**Contents**
+ [Configurazione con NuGet CodeCatalyst](#nuget-configure-cli)
+ [Consumo di pacchetti NuGet da un repository CodeCatalyst](#nuget-consume-cli)
+ [Consumo di pacchetti da .org a NuGet NuGet CodeCatalyst](#nuget-consume-nuget-gallery)
+ [Pacchetti di pubblicazione su NuGet CodeCatalyst](#nuget-publish-cli)
## Configurazione con NuGet CodeCatalyst
Per eseguire la configurazione NuGet CodeCatalyst, aggiungi un endpoint del repository e un token di accesso personale al tuo file di NuGet configurazione per consentire o connetterti al tuo repository di pacchetti. `nuget` `dotnet` CodeCatalyst
**Da configurare con il tuo repository NuGet di pacchetti CodeCatalyst**
1. Apri la CodeCatalyst console all'indirizzo [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Nella pagina di panoramica del progetto, scegli **Pacchetti**.
1. Scegli il tuo repository di pacchetti dall'elenco dei repository di pacchetti.
1. Scegli **Connect to repository.**
1. Nella finestra di dialogo **Connect to repository**, scegliete **NuGet**or **dotnet** dall'elenco dei client del gestore di pacchetti.
1. Avrai bisogno di un token di accesso personale (PAT) con cui autenticarti. NuGet CodeCatalyst Se ne hai già uno, puoi usarlo. In caso contrario, puoi crearne uno qui.
1. Scegli **Crea token**.
1. Scegli **Copia** per copiare il tuo PAT.
**avvertimento**
Non potrai più vedere o copiare il tuo PAT dopo aver chiuso la finestra di dialogo.
1. Configura `nuget` o utilizza `dotnet` l' NuGet endpoint e il PAT del repository. CodeCatalyst Sostituisci i seguenti valori.
**Nota**
Se si copiano le istruzioni dalla console, i seguenti valori devono essere aggiornati automaticamente e non devono essere modificati.
+ *username*Sostituiscili con il tuo nome CodeCatalyst utente.
+ *PAT*Sostituiscilo con il tuo CodeCatalyst PAT.
+ Sostituisci *space\$1name* con il nome CodeCatalyst dello spazio.
+ Sostituisci *proj\$1name* con il nome CodeCatalyst del tuo progetto.
+ *repo\$1name*Sostituiscilo con il nome CodeCatalyst del repository dei pacchetti.
1. Per `nuget`, utilizzare il comando `nuget sources add`.
```
nuget sources add -name "repo_name" -Source "https://packages.region.codecatalyst.aws/nuget/space_name/proj_name/repo_name/v3/index.json" -username "username" -password "PAT"
```
1. Per `dotnet`, utilizzare il comando `dotnet nuget add source`.
**Utenti Linux e macOS**: poiché la crittografia non è supportata su piattaforme diverse da Windows, è necessario aggiungere il `--store-password-in-clear-text` flag al comando seguente. Tieni presente che questa operazione memorizzerà la password come testo semplice nel file di configurazione.
```
dotnet nuget add source "https://packages.region.codecatalyst.aws/nuget/space_name/proj_name/repo_name/v3/index.json" -n "proj_name/repo_name" -u "username" -p "PAT" --store-password-in-clear-text
```
Dopo aver configurato NuGet con CodeCatalyst, potete [utilizzare NuGet i pacchetti](#nuget-consume-cli) archiviati nel vostro CodeCatalyst repository o in uno dei suoi repository upstream e [pubblicare NuGet ](#nuget-publish-cli) i pacchetti nel vostro repository. CodeCatalyst
## Consumo di pacchetti NuGet da un repository CodeCatalyst
Dopo aver [configurato NuGet con CodeCatalyst](#nuget-configure-cli), puoi utilizzare i NuGet pacchetti archiviati nel tuo CodeCatalyst repository o in uno dei suoi repository upstream.
Per utilizzare una versione del pacchetto da un CodeCatalyst repository o da uno dei suoi repository upstream con nuget o dotnet, esegui il comando seguente. Sostituiscilo *packageName* con il nome del pacchetto che desideri consumare e *packageSourceName* con il nome sorgente del tuo repository di CodeCatalyst pacchetti nel tuo file di NuGet configurazione, che dovrebbe essere il nome del repository.
**Per installare un pacchetto con `dotnet`**
```
dotnet add packageName --source packageSourceName
```
**Per installare un pacchetto con `nuget`**
```
nuget install packageName --source packageSourceName
```
*Per ulteriori informazioni, consulta [Gestire i pacchetti utilizzando la CLI di nuget o Installare e gestire i](https://docs.microsoft.com/en-us/nuget/consume-packages/install-use-packages-nuget-cli) [pacchetti utilizzando la CLI dotnet](https://docs.microsoft.com/en-us/nuget/consume-packages/install-use-packages-dotnet-cli) nella documentazione Microsoft.*
## Consumo di pacchetti da .org a NuGet NuGet CodeCatalyst
**È possibile utilizzare NuGet pacchetti da [NuGet.org](https://www.nuget.org/) tramite un CodeCatalyst repository configurando il repository con una connessione upstream a .org. NuGet** I pacchetti consumati da **NuGet.org vengono importati** e archiviati nel tuo repository. CodeCatalyst
**Per consumare pacchetti da .org NuGet**
1. Se non l'hai già fatto, configura il tuo gestore di NuGet pacchetti con il tuo repository di CodeCatalyst pacchetti seguendo i passaggi riportati di seguito. [Configurazione con NuGet CodeCatalyst](#nuget-configure-cli)
1. Assicurati che il tuo repository abbia aggiunto **NuGet.org** come connessione upstream. **Puoi controllare quali sorgenti upstream vengono aggiunte o aggiungere **NuGet.org** come fonte upstream seguendo le istruzioni e scegliendo lo store repository. [Aggiunta di un repository upstream](packages-upstream-repositories-add.md) NuGet **
## Pacchetti di pubblicazione su NuGet CodeCatalyst
Dopo aver [configurato NuGet con CodeCatalyst](#nuget-configure-cli), puoi utilizzare `nuget` o pubblicare le versioni dei pacchetti nei `dotnet` repository. CodeCatalyst
Per inviare una versione del pacchetto a un CodeCatalyst repository, esegui il comando seguente con il percorso completo del `.nupkg` file e il nome sorgente del CodeCatalyst repository nel file di configurazione NuGet .
**Per pubblicare un pacchetto con `dotnet`**
```
dotnet nuget push path/to/nupkg/SamplePackage.1.0.0.nupkg --source packageSourceName
```
**Per pubblicare un pacchetto con `nuget`**
```
nuget push path/to/nupkg/SamplePackage.1.0.0.nupkg --source packageSourceName
```
# NuGet normalizzazione del nome del pacchetto, della versione e del nome dell'asset
CodeCatalyst normalizza i nomi e le versioni dei pacchetti e delle risorse prima di archiviarli, il che significa che i nomi o le versioni dei pacchetti CodeCatalyst possono essere diversi da quelli forniti al momento della pubblicazione del pacchetto o della risorsa.
**Normalizzazione dei nomi dei pacchetti:** CodeCatalyst normalizza i nomi dei NuGet pacchetti convertendo tutte le lettere in minuscolo.
**Normalizzazione della versione del NuGet pacchetto:** CodeCatalyst normalizza le versioni dei pacchetti utilizzando lo stesso schema di. NuGet Le seguenti informazioni sono tratte dai [numeri di versione normalizzati](https://docs.microsoft.com/en-us/nuget/concepts/package-versioning#normalized-version-numbers) riportati nella documentazione. NuGet
+ Gli zeri iniziali vengono rimossi dai numeri di versione:
+ `1.00`viene trattato come `1.0`
+ `1.01.1`è trattato come `1.1.1`
+ `1.00.0.1`è trattato come `1.0.0.1`
+ Verrà omesso uno zero nella quarta parte del numero di versione:
+ `1.0.0.0`viene trattato come `1.0.0`
+ `1.0.01.0`è trattato come `1.0.1`
+ SemVer i metadati della build 2.0.0 vengono rimossi:
+ `1.0.7+r3456`viene trattato come `1.0.7`
**Normalizzazione del nome dell'asset del pacchetto:** CodeCatalyst costruisce il nome dell'asset del NuGet pacchetto dal nome del pacchetto e dalla versione del pacchetto normalizzati.
# NuGet compatibilità
Questa guida contiene informazioni sulla CodeCatalyst compatibilità con diversi NuGet strumenti e versioni.
**Topics**
+ [NuGet Compatibilità generale](#nuget-version-support)
+ [NuGet supporto da riga di comando](#nuget-command-line-support)
## NuGet Compatibilità generale
CodeCatalyst supporta NuGet 4.8 e versioni successive.
CodeCatalyst supporta solo la versione 3 del NuGet protocollo HTTP. Ciò significa che alcuni comandi CLI che si basano sulla versione 2 del protocollo non sono supportati. Per ulteriori informazioni, consulta la [supporto per i comandi nuget](#nuget-command-support) sezione seguente.
CodeCatalyst non supporta PowerShellGet 2.x.
## NuGet supporto da riga di comando
CodeCatalyst supporta gli NuGet strumenti CLI (`nuget`) e.NET Core (`dotnet`).
### supporto per i comandi nuget
Poiché supporta CodeCatalyst solo il protocollo HTTP NuGet di V3 of, i seguenti comandi non funzioneranno se utilizzati contro risorse: CodeCatalyst
+ `list`: Il `nuget list` comando visualizza un elenco di pacchetti da una determinata fonte. Per ottenere un elenco di pacchetti in un repository di CodeCatalyst pacchetti, accedi al repository nella CodeCatalyst console.
# Uso di Python
Questi argomenti descrivono come usare`pip`, il gestore di pacchetti Python e `twine` l'utilità di pubblicazione dei pacchetti Python con. CodeCatalyst
**Topics**
+ [Configurazione di pip e installazione di pacchetti Python](packages-python-pip.md)
+ [Configurazione di Twine e pubblicazione di pacchetti Python](packages-python-twine.md)
+ [Normalizzazione dei nomi dei pacchetti in Python](python-name-normalization.md)
+ [Compatibilità con Python](packages-python-compatibility.md)
# Configurazione di pip e installazione di pacchetti Python
Per `pip` utilizzarlo CodeCatalyst, è necessario connettersi `pip` al repository dei pacchetti e fornire un token di accesso personale per l'autenticazione. È possibile visualizzare le istruzioni per la connessione `pip` al repository dei pacchetti nella CodeCatalyst console. Dopo l'autenticazione e la connessione `pip` CodeCatalyst, puoi eseguire `pip` i comandi.
**Contents**
+ [Installazione di pacchetti Python da CodeCatalyst con pip](#pip-install)
+ [Consumo di pacchetti Python da PyPI tramite CodeCatalyst](#pip-install-pypi)
+ [supporto per i comandi pip](#pip-command-support)
+ [Comandi supportati che interagiscono con un repository](#supported-pip-commands-that-interact-with-a-repository)
+ [Comandi lato client supportati](#supported-pip-client-side-commands)
## Installazione di pacchetti Python da CodeCatalyst con pip
Le seguenti istruzioni spiegano come `pip` configurare l'installazione dei pacchetti Python dal tuo CodeCatalyst repository di pacchetti o da uno dei suoi repository upstream.
**Da configurare e utilizzare `pip` per installare i pacchetti Python dal tuo CodeCatalyst repository di pacchetti**
1. [Apri la CodeCatalyst console all'indirizzo https://codecatalyst.aws/.](https://codecatalyst.aws/)
1. Nella pagina di panoramica del progetto, scegli **Pacchetti**.
1. Scegli il tuo repository di pacchetti dall'elenco dei repository di pacchetti.
1. Scegli **Connect to repository.**
1. Nella finestra di dialogo **Connect to repository**, scegli **pip** dall'elenco dei client del gestore di pacchetti.
1. Avrai bisogno di un token di accesso personale (PAT) con cui autenticare pip. CodeCatalyst Se ne hai già uno, puoi usarlo. In caso contrario, puoi crearne uno qui.
1. Scegli **Crea token**.
1. Scegli **Copia** per copiare il tuo PAT.
**avvertimento**
Non potrai più vedere o copiare il tuo PAT dopo aver chiuso la finestra di dialogo.
1. Utilizzate il `pip config` comando per impostare l'URL e le credenziali del CodeCatalyst registro. Sostituisci i seguenti valori.
**Nota**
Se si copiano le istruzioni dalla console, i seguenti valori devono essere aggiornati automaticamente e non devono essere modificati.
+ *username*Sostituiscili con il tuo nome CodeCatalyst utente.
+ *PAT*Sostituiscilo con il tuo CodeCatalyst PAT.
+ *space\$1name*Sostituiscilo con il nome CodeCatalyst dello spazio.
+ *proj\$1name*Sostituiscilo con il nome CodeCatalyst del tuo progetto.
+ *repo\$1name*Sostituiscilo con il nome CodeCatalyst del repository dei pacchetti.
```
pip config set global.index-url https://username:PAT@https://packages.region.codecatalyst.aws/pypi/space_name/proj_name/repo_name/simple/
```
1. Supponendo che un pacchetto sia presente nel tuo repository o in uno dei suoi repository originali, puoi installarlo con. `pip install` Ad esempio, utilizzate il comando seguente per installare il pacchetto. `requests`
```
pip install requests
```
Utilizzate l'`-i`opzione per tornare temporaneamente all'installazione dei pacchetti da [https://pypi.org](https://pypi.org) anziché dal vostro repository di CodeCatalyst pacchetti.
```
pip install -i https://pypi.org/simple requests
```
## Consumo di pacchetti Python da PyPI tramite CodeCatalyst
**È possibile utilizzare pacchetti Python dal Python [Package Index (PyPI)](https://www.pypi.org/) tramite un CodeCatalyst repository configurando il repository con una connessione upstream a PyPI.** I pacchetti consumati da **PyPI vengono importati** e archiviati nel tuo repository. CodeCatalyst
**Per utilizzare pacchetti da PyPI**
1. Se non l'hai già fatto, configura pip con il tuo repository di CodeCatalyst pacchetti seguendo i passaggi indicati. [Installazione di pacchetti Python da CodeCatalyst con pip](#pip-install)
1. Assicurati che il tuo repository abbia aggiunto **PyPI** come sorgente upstream. Puoi controllare quali sorgenti upstream vengono aggiunte o aggiungere **PyPI** come sorgente upstream seguendo le istruzioni e scegliendo il repository [Aggiunta di un repository upstream](packages-upstream-repositories-add.md) **PyPI** store.
Per ulteriori informazioni sulla richiesta di pacchetti dai repository upstream, consulta. [Richiesta di una versione del pacchetto con repository upstream](packages-upstream-repositories-request.md)
## supporto per i comandi pip
Le sezioni seguenti riepilogano i comandi pip supportati dai CodeCatalyst repository, oltre ai comandi specifici che non sono supportati.
**Topics**
+ [Comandi supportati che interagiscono con un repository](#supported-pip-commands-that-interact-with-a-repository)
+ [Comandi lato client supportati](#supported-pip-client-side-commands)
### Comandi supportati che interagiscono con un repository
Questa sezione elenca `pip` i comandi in cui il `pip` client effettua una o più richieste al registro con cui è stato configurato. È stato verificato che questi comandi funzionino correttamente quando vengono richiamati CodeCatalyst su un archivio di pacchetti.
****
| Comando | Description |
| --- | --- |
| [installare](https://pip.pypa.io/en/stable/reference/pip_install/) | Installa pacchetti. |
| [scaricare](https://pip.pypa.io/en/stable/reference/pip_download/) | Scarica i pacchetti. |
CodeCatalyst non implementa`pip search`. Se hai configurato `pip` con un repository di CodeCatalyst pacchetti, l'esecuzione `pip search` cercherà e mostrerà i pacchetti da [PyPI](https://pypi.org/).
### Comandi lato client supportati
Questi comandi non richiedono alcuna interazione diretta con un repository, quindi CodeCatalyst non è necessario fare nulla per supportarli.
****
| Comando | Description |
| --- | --- |
| [disinstallare](https://pip.pypa.io/en/stable/reference/pip_uninstall/) | Disinstalla i pacchetti. |
| [congelare](https://pip.pypa.io/en/stable/reference/pip_freeze/) | Visualizza i pacchetti installati nel formato dei requisiti. |
| [elenco](https://pip.pypa.io/en/stable/reference/pip_list/) | Elenca i pacchetti installati. |
| [sh](https://pip.pypa.io/en/stable/reference/pip_show/)ow | Mostra informazioni sui pacchetti installati. |
| [controlla](https://pip.pypa.io/en/stable/reference/pip_check/) | Verifica che i pacchetti installati abbiano dipendenze compatibili. |
| [configurazione](https://pip.pypa.io/en/stable/reference/pip_config/) | Gestisci la configurazione locale e globale. |
| [ruota](https://pip.pypa.io/en/stable/reference/pip_wheel/) | Costruisci ruote in base alle tue esigenze. |
| [cancelletto](https://pip.pypa.io/en/stable/reference/pip_hash/) | Calcola gli hash degli archivi dei pacchetti. |
| [completamento](https://pip.pypa.io/en/stable/user_guide/#command-completion) | Aiuta a completare i comandi. |
| [debug](https://pip.pypa.io/en/stable/reference/pip_debug/) | Mostra informazioni utili per il debug. |
| aiuto | Mostra l'aiuto per i comandi. |
# Configurazione di Twine e pubblicazione di pacchetti Python
Per `twine` utilizzarlo CodeCatalyst, è necessario connettersi `twine` al repository dei pacchetti e fornire un token di accesso personale per l'autenticazione. È possibile visualizzare le istruzioni per la connessione `twine` al repository dei pacchetti nella CodeCatalyst console. Dopo l'autenticazione e la connessione `twine` CodeCatalyst, puoi eseguire `twine` i comandi.
## Pacchetti di pubblicazione su CodeCatalyst with Twine
Le seguenti istruzioni spiegano come autenticarsi e connettersi `twine` al repository dei CodeCatalyst pacchetti.
**Da configurare e utilizzare `twine` per pubblicare pacchetti nel proprio CodeCatalyst repository di pacchetti**
1. Apri la CodeCatalyst console all'indirizzo [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Nella pagina di panoramica del progetto, scegli **Pacchetti**.
1. Scegli il tuo repository di pacchetti dall'elenco dei repository di pacchetti.
1. Scegli **Connect to repository.**
1. Nella finestra di dialogo **Connect to repository**, scegli **Twine** dall'elenco dei client del gestore di pacchetti.
1. Avrai bisogno di un token di accesso personale (PAT) con cui autenticare Twine. CodeCatalyst Se ne hai già uno, puoi usarlo. In caso contrario, puoi crearne uno qui.
1. Scegli **Crea token**.
1. Scegli **Copia** per copiare il tuo PAT.
**avvertimento**
Non potrai più vedere o copiare il tuo PAT dopo aver chiuso la finestra di dialogo.
1. È possibile configurare twine con un `.pypirc` file o con variabili di ambiente.
1. **Da configurare con un `.pypirc` file.**
Apri `~/.pypirc` nell'editor che preferisci.
Aggiungi un server di indicizzazione per CodeCatalyst, incluso il repository, il nome utente e il PAT che hai creato e copiato in un passaggio precedente. Sostituisci i seguenti valori.
**Nota**
Se si copiano le istruzioni dalla console, i seguenti valori devono essere aggiornati automaticamente e non devono essere modificati.
+ *username*Sostituiscili con il tuo nome CodeCatalyst utente.
+ *PAT*Sostituiscilo con il tuo CodeCatalyst PAT.
+ *space\$1name*Sostituiscilo con il nome CodeCatalyst dello spazio.
+ *proj\$1name*Sostituiscilo con il nome CodeCatalyst del tuo progetto.
+ *repo\$1name*Sostituiscilo con il nome CodeCatalyst del repository dei pacchetti.
```
[distutils]
index-servers = proj-name/repo-name
[proj-name/repo-name]
repository = https://packages.region.codecatalyst.aws/pypi/space_name/proj_name/repo_name/
password = PAT
username = username
```
1. **Da configurare con variabili di ambiente.**
Imposta le seguenti variabili di ambiente. Nel `TWINE_REPOSITORY_URL` valore*space\$1name*, *proj\$1name* aggiorna e *repo\$1name* inserisci i nomi CodeCatalyst dello spazio, del progetto e del repository dei pacchetti.
```
export TWINE_USERNAME=username
```
```
export TWINE_PASSWORD=PAT
```
```
export TWINE_REPOSITORY_URL="https://packages.region.codecatalyst.aws/pypi/space_name/proj_name/repo_name/"
```
1. Pubblica una distribuzione Python con il `twine upload` comando.
# Normalizzazione dei nomi dei pacchetti in Python
CodeCatalyst normalizza i nomi dei pacchetti prima di memorizzarli, il che significa che i nomi dei pacchetti CodeCatalyst possono essere diversi dal nome fornito quando il pacchetto è stato pubblicato.
Per i pacchetti Python, quando si esegue la normalizzazione il nome del pacchetto è in minuscolo e tutte le istanze dei caratteri vengono sostituite con un `.` singolo `-` carattere. `_` `-` Quindi i nomi dei pacchetti e sono normalizzati `pigeon_cli` e `pigeon.cli` memorizzati come. `pigeon-cli` Il nome non normalizzato può essere usato da pip e twine. Per ulteriori informazioni sulla normalizzazione dei nomi dei pacchetti Python, vedere [PEP 503](https://www.python.org/dev/peps/pep-0503/#normalized-names) nella documentazione di Python.
# Compatibilità con Python
Sebbene CodeCatalyst non supporti l'`/simple/`API, supporta le operazioni `Legacy` API. CodeCatalyst non supporta le operazioni PyPI `XML-RPC` o `JSON` API.
Per ulteriori informazioni, vedere quanto segue nel repository della Python Packaging Authority. GitHub
+ [API legacy](https://warehouse.pypa.io/api-reference/legacy.html)
+ [API XML-RPC](https://github.com/pypi/warehouse/blob/main/docs/dev/api-reference/xml-rpc.rst)
+ [API JSON](https://docs.pypi.org/api/json/)
# Quote per i pacchi
La tabella seguente descrive le quote e i limiti per i pacchi in Amazon CodeCatalyst. Per ulteriori informazioni sulle quote in Amazon CodeCatalyst, consulta[Quote per CodeCatalyst](quotas.md).
| Risorsa | Quota predefinita |
| --- | --- |
| Archivi di pacchetti | Massimo 1000 per spazio. |
| Archivi diretti a monte | Massimo 10 per archivio di pacchetti. |
| Ricerca negli archivi di pacchetti upstream | Massimo 25 repository upstream ricercati per versione del pacchetto richiesta. |
| Dimensione del file di asset del pacchetto | Massimo 5 GB per risorsa del pacchetto. |
| Risorse del pacchetto | Massimo 150 per versione del pacchetto. |